GH Actions: various tweaks

[jrfnl]

Description

Workflow update in response to #210 (comment)

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 archived 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

Motivation and context

See the commit descriptions.

How has this been tested?

By running the workflow ;-)

PR checklist

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING.md document.
• I have added tests to cover my changes.

[jrfnl]

Found one more thing & added an extra commit to address it.

[jrfnl]

P.S.: critical review warranted. The "code cov not on forks" commit may still need to be removed.

[ramsey]

Thanks! This is great!

[ramsey]

Nice! I didn't know you could do this to limit certain jobs to a specific repository.

[ramsey]

The "code cov not on forks" commit may still need to be removed.

The only concern I have for this one is whether this means the coverage check will not run on PRs. However, it appears to have run on this PR, so maybe that's not an issue?

[jrfnl]

The "code cov not on forks" commit may still need to be removed.

The only concern I have for this one is whether this means the coverage check will not run on PRs. However, it appears to have run on this PR, so maybe that's not an issue?

Well, PRs should be regarded as coming from this repo, so it should be okay. I could add an extra condition github.event_name == 'push' to only limit it on pushes, not pull requests ?

[ramsey]

I could add an extra condition github.event_name == 'push' to only limit it on pushes, not pull requests ?

I don't think that's necessary. I'll go ahead and merge it, and we'll see how it goes. 😄