Commits on Dec 28, 2021

1. ci: generate code coverage report

   

   ramsey committedDec 28, 2021
   Configuration menu

   • View commit details
   • Copy full SHA for ef0ac57
   • Browse repository at this point

   Copy the full SHA

   ef0ac57View commit details

   Browse the repository at this point in the history

2. Do not append always empty restore_key (#216)

   

   szepeviktor authoredDec 28, 2021
   Configuration menu

   • View commit details
   • Copy full SHA for 6e86502
   • Browse repository at this point

   Copy the full SHA

   6e86502View commit details

   Browse the repository at this point in the history

3. GH Actions: various tweaks (#217) …

   * GH Actions: allow for manually triggering a workflowTriggering 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 branchPreviously, 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 orderThe 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 forksOftentimes, 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-rubyCo-authored-by: jrfnl <jrfnl@users.noreply.github.com>

   

   jrfnl andjrfnl authoredDec 28, 2021
   Configuration menu

   • View commit details
   • Copy full SHA for 6ba32f2
   • Browse repository at this point

   Copy the full SHA

   6ba32f2View commit details

   Browse the repository at this point in the history

4. fix: don't error out on out-of-sync lock file (#213) …

   As far as I can see, the `--no-check-lock` argument has been available since Composer 1.0, so adding this argument to the `composer validate` command should be safe and should prevent the issues as reported in#206.Includes tests (though the test isn't running properly yet).Fixes#206Co-authored-by: jrfnl <jrfnl@users.noreply.github.com>

   

   jrfnl andjrfnl authoredDec 28, 2021
   Configuration menu

   • View commit details
   • Copy full SHA for 713bde7
   • Browse repository at this point

   Copy the full SHA

   713bde7View commit details

   Browse the repository at this point in the history