Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* GH Actions: allow for manually triggering a workflow Triggering a workflow for a branch manually is not supported by default in GH Actions, but has to be explicitly allowed. This is useful if, for instance, an external action script or composer dependency has broken. Once a fix is available, failing builds for open PRs can be retriggered manually instead of having to be re-pushed to retrigger the workflow. Ref: https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/ * GH Actions: auto-cancel previous builds for same branch Previously, in Travis, when the same branch was pushed again and the "Auto cancellation" option on the "Settings" page had been turned on (as it was for most repos), any still running builds for the same branch would be stopped in favour of starting the build for the newly pushed version of the branch. To enable this behaviour in GH Actions, a `concurrency` configuration needs to be added to each workflow for which this should applied to. More than anything, this is a way to be kind to GitHub by not wasting resources which they so kindly provide to us for free. Refs: * https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/ * https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#concurrency * GH Actions: change job order The code coverage job is running the same command as the Expect tests. I'd like to suggest to only run code coverage when the Expect tests actually pass. To that end, I'm suggesting to reverse the order of the jobs in the workflow (`test` first, `code-coverage` second) and make the `code-coverage` job dependent on the `test` run (via `needs`), so it only runs when the tests pass. * GH Actions: don't run code coverage on forks Oftentimes, the "owner" of a fork won't have permission to upload code coverage data for the "main" repo and it would be very rare for them to have a CodeCov account setup linked to their fork, so a code coverage run can be limited to the "main" repo only. * GH Actions: version update for `codecov/codecov-action` A while back the `codecov/codecov-action` released a new major. As per the release notes: > On February 1, 2022, the v1 uploader will be full sunset and no longer function. This is due to the deprecation of the underlying bash uploader. This version uses the new uploader. Considering Feb 2022 is creeping closer every day, updating seems prudent. > Multiple fields have not been transferred from the bash uploader or have been deprecated. Notably many of the `functionalities` and `gcov_` arguments have been removed. This repo does not seem to be affected by this. Refs: * https://github.com/codecov/codecov-action/releases/tag/v2.0.0 * https://github.com/codecov/codecov-action/releases/tag/v2.0.1 * https://github.com/codecov/codecov-action/releases/tag/v2.0.2 * https://github.com/codecov/codecov-action/releases/tag/v2.0.3 * https://github.com/codecov/codecov-action/releases/tag/v2.1.0 * GH Actions: only run the action tests when the "expect" tests pass ... to be kind to GitHub for the resources they so freely provide, as when the `expect` tests fail, a commit/PR isn't ready for merge yet anyway. * GH Actions: add a job to run Composer normalize * GH Actions: use `ruby/setup-ruby` The `actions/setup-ruby` action has been archieved and is no longer maintained. Per the note in the README: > Please note: This action is deprecated and should no longer be used. The team at GitHub has ceased making and accepting code contributions or maintaining issues tracker. Please, migrate your workflows to the ruby/setup-ruby, which is being actively maintained by the official Ruby organization. This switches the workflow over to the `ruby/setup-ruby` action. Ref: https://github.com/ruby/setup-ruby Co-authored-by: jrfnl <jrfnl@users.noreply.github.com>
- Loading branch information