Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add unit tests #364

Closed
ipfaze opened this issue Sep 27, 2023 · 9 comments · Fixed by #410
Closed

Add unit tests #364

ipfaze opened this issue Sep 27, 2023 · 9 comments · Fixed by #410
Assignees
Labels
low Low Priority Issue

Comments

@ipfaze
Copy link
Contributor

ipfaze commented Sep 27, 2023

As discussed in PR #341, adding unit tests would be very useful as we will be able to maintain and improve more easily our php-buildpack.

@ipfaze ipfaze added the IST label Sep 27, 2023
@ipfaze
Copy link
Contributor Author

ipfaze commented Sep 27, 2023

Issue #236 is currently 🪦 Stale waiting for this one to be tackled.

@ipfaze ipfaze added low Low Priority Issue and removed IST labels Oct 13, 2023
@Frzk
Copy link
Contributor

Frzk commented Oct 17, 2023

First step consists in:

  • adding a basic unit test using shUnit2
  • making it runnable with make test
  • including the process in a GitHub Actions Workflow
  • making it run on both scalingo-20 and scalingo-22

@Frzk Frzk self-assigned this Oct 17, 2023
@Frzk
Copy link
Contributor

Frzk commented Feb 12, 2024

Maybe we can close this one since we have a few tests now?
If not, could you please make it more specific (what exactly is expected?) ? Thanks!

@ipfaze
Copy link
Contributor Author

ipfaze commented Feb 14, 2024

How did you add unit tests in this buildpack? Did you link PRs to an issue?

@EtienneM
Copy link
Member

I think we should close this issue when tests are automatically executed by the CI. Is it the case?

@Frzk
Copy link
Contributor

Frzk commented Feb 15, 2024

The CI is triggered when a PR is opened: https://github.com/Scalingo/php-buildpack/actions
Also, first unit tests were introduced in #369

@EtienneM
Copy link
Member

The CI is triggered when a PR is opened

Shouldn't we trigger the CI for every push? I'm not fluent in GitHub Action so I'm not sure this is the case here. If that's the case, then I agree we can close this issue :)

@Frzk
Copy link
Contributor

Frzk commented Feb 15, 2024

Currently the CI is triggered when the following events are happening:

  • a push event occurs on the main branch: it doesn't really make any sense, since we are using the master branch.
  • a pull_request event occurs on the repo: the workflow runs when a pull request is opened or reopened or when the head branch of the pull request is updated (a commit is made on the branch from which the PR is made) (full doc here: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request)
  • a workflow_dispatch event occurs, which means someone pushed the button to trigger it manually.

I guess we could either remove the push event or, if we want to keep it, make sure it's triggered when a push is done on the master branch.

WDYT?

@EtienneM
Copy link
Member

Yes I think we need to update the push event so that it triggers for push on the master branch. Then we can close this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
low Low Priority Issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants