-
-
Notifications
You must be signed in to change notification settings - Fork 8
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
CI: switch to GitHub Actions #239
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit: * Adds a GH Actions workflow for the CI checks which were previously run on Travis in the `sniff` stage. While these aren't 100% CS (= code style) checks, for the badge and workflow display, `CS` still seemed the most descriptive name. * Removes that part of the `.travis.yml` configuration. * Adds a "Build Status" badge in the Readme to use the results from this particular GH Actions runs. Notes: Builds will run on all pushes and on pull requests, with the exception of those just modifying files which are irrelevant to this workflow.
This commit: * Adds a GH Actions workflow for the CI checks which were previously run on Travis in the `docs` stage. * Removes that part of the `.travis.yml` configuration. * Adds a "Build Status" badge in the Readme to use the results from this particular GH Actions run. Notes: * Builds will run on all pushes and pull requests which contain changes to files in the `docs` folder. * With the way the `setup-ruby` action works, gems will be installed in a `docs/vendor` folder. For that reason, that folder now needs to be excluded from the build.
This commit: * Adds a GH Actions workflow for the CI checks which were previously run on Travis in the `quicktest` stage. * Removes that part of the `.travis.yml` configuration. Notes: 1. Previously, this "stage" would run on all `push` events, except when merging to `master` or `develop`. The current set-up still does so, with one exception: pushes to `develop` will now use this quicktest instead of the full test. `develop` is a protected branch anyhow, so all merges will already have had the full test run in the pull request. For merges to `master`, the full Test run will still be used as that will generally mean we're getting ready to tag a release and some extra safety checking before a release is not a bad thing. 2. This also updates the "high" PHP version for the "quicktest" against PHPCS `dev-master` from PHP 7.4 to PHP 8.0 by using `latest` which translates to "latest stable PHP release".
This was referenced Dec 21, 2020
0243790
to
9663698
Compare
This commit: * Adds a GH Actions workflow for the CI checks which were previously run on Travis in the `test` and `coverage` stages. * Removes the, now redundant, `.travis.yml` configuration. * Updates the `.gitattributes` file. * Updates the "Build Status" badge in the Readme to use the results from the GH `Test` Actions runs. * Updates the "Tested on" badge in the Readme to include PHP 8. * Updates a test file which mentioned Travis. Notes: 1. Each of these jobs has a `needs` dependency on the previous job to prevent it from starting if the previous job failed. While not 100% necessary, this is just an efficiency tweak, being kind to the free service being offered as we know that if linting fails, the tests will fail etc. 2. The builds in the `test` and `coverage` jobs are essentially the same as previously run on Travis, though PHP 8.0 is now fully accounted for and `8.1` is set as `nightly`. 3. Previously, this "stage" would run on all `pull requests` events. The current set-up still does so, with one addition: pushes to `master` (merges) will now also use this workflow instead of the quicktest. This replaces the full run on tagging a release, meaning that thing will essentially be the same. 4. As there are a couple of jobs which are "allowed to fail" (`experimental` = true), the build status will unfortunately show as "failed", even though all non-experimental jobs have succeeded. This is a known issue in GHA: https://github.com/actions/toolkit/issues/399
9663698
to
846075c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
CI: switch to GitHub Actions - step 1: sniff stage
This commit:
sniff
stage.While these aren't 100% CS (= code style) checks, for the badge and workflow display,
CS
still seemed the most descriptive name..travis.yml
configuration.Notes:
Builds will run on all pushes and on pull requests, with the exception of those just modifying files which are irrelevant to this workflow.
CI: switch to GitHub Actions - step 2: docs stage
This commit:
docs
stage..travis.yml
configuration.Notes:
docs
folder.setup-ruby
action works, gems will be installed in adocs/vendor
folder. For that reason, that folder now needs to be excluded from the build.CI: switch to GitHub Actions - step 3: quick test stage
This commit:
quicktest
stage..travis.yml
configuration.Notes:
push
events, except when merging tomaster
ordevelop
.The current set-up still does so, with one exception: pushes to
develop
will now use this quicktest instead of the full test.develop
is a protected branch anyhow, so all merges will already have had the full test run in the pull request.For merges to
master
, the full Test run will still be used as that will generally mean we're getting ready to tag a release and some extra safety checking before a release is not a bad thing.dev-master
from PHP 7.4 to PHP 8.0 by usinglatest
which translates to "latest stable PHP release".CI: switch to GitHub Actions - step 4: test and coverage stage
This commit:
test
andcoverage
stages..travis.yml
configuration..gitattributes
file.Test
Actions runs.Notes:
needs
dependency on the previous job to prevent it from starting if the previous job failed.While not 100% necessary, this is just an efficiency tweak, being kind to the free service being offered as we know that if linting fails, the tests will fail etc.
test
andcoverage
jobs are essentially the same as previously run on Travis, though PHP 8.0 is now fully accounted for and8.1
is set asnightly
.pull requests
events.The current set-up still does so, with one addition: pushes to
master
(merges) will now also use this workflow instead of the quicktest.This replaces the full run on tagging a release, meaning that thing will essentially be the same.
experimental
= true), the build status will unfortunately show as "failed", even though all non-experimental jobs have succeeded.This is a known issue in GHA: Please support something like "allow-failure" for a given job actions/runner#2347
Future scope:
In the future additional workflows/jobs could be added to, for instance,
For now, this PR just converts the existing checks to GH Actions.