CI: switch to GitHub Actions

[jrfnl]

Summary

This PR can be summarized in the following changelog entry:

• CI/QA is now run via GitHub Actions

Relevant technical choices:

👉🏻 This PR will be easiest to review by reviewing each commit individually.

CI: switch to GitHub Actions - step 1: code style

This commit:

• Adds a GH Actions workflow for the CI code style check and to validate the composer.json file.
• Removes those actions from the .travis.yml configuration.

Notes:

1. Builds will run on all pushes and on pull requests, except pushes to master.
2. Builds can also be manually triggered. Note: manual triggering of builds has to be explicitly allowed. This is not a feature which is enabled by default.
3. 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.
4. Composer dependency downloads will be cached for faster builds using a predefined GH action specifically created for this purpose. The alternative would be to handle the caching manually, which would add three extra steps to the script. Note: Caching works differently between Travis and GH Actions. On GH Actions, once a cache has been created, it can't be updated. It can only be replaced by a new cache with a different key. As the PHP version, the composer.json and a potential composer.lock hash are all part of the key used by the above mentioned action, this difference should not have a significant impact. Ref: https://docs.github.com/en/actions/advanced-guides/caching-dependencies-to-speed-up-workflows
5. The CS check will display the results in the actions script output log, as well as display any violations found inline in the GitHub code view using the cs2pr tool.

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 composer validate command will now only be run against the PHP version used in the cs script (PHP 7.4), not against multiple PHP versions.

CI: switch to GitHub Actions - step 2: 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.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. 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.

CI: switch to GitHub Actions - step 3: linting

This commit:

• Adds a GH Actions workflow for the PHP lint CI check.
• Removes all references to that action from the .travis.yml configuration, as well as does some additional clean up of parts of the Travis script which have now become unused.

Notes:

1. Builds will run on:
   • Select pushes using branch filtering similar to before.
   • All pull requests.
   • When manually triggered. Note: manual triggering of builds has to be explicitly allowed. This is not a feature which is enabled by default.
2. 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.
3. The default ini settings used by the setup-php action are based on the php.ini-production configuration. This means that error_reporting=E_ALL & ~E_DEPRECATED & ~E_STRICT, display_errors is set to Off and zend.assertions is set to -1 (= do not compile). For the purposes of CI, especially for linting and testing code, I'd recommend running with zend.assertions=-1,error_reporting=-1anddisplay_errors=Onto ensure **all** PHP notices are shown. Note: the defaults will be changed in the next major ofsetup-phpto be based on thephp.ini-develop` configuration, but that may still be a while off. Refs:
   • shivammathur/setup-php#450
   • shivammathur/setup-php#469
4. While the setup-php action offers the ability to install the PHAR file for Parallel Lint, I've elected not to use that option as it would mean that we would not be able to use the composer lint script in the workflow, which would mean that the CLI arguments would have to be duplicated between the composer.json file and the lint.yml file. IMO, that would make this a typical point of failure where updates would be done in one, but not the other. If, at some point in the future, the Parallel Lint tool would start to support a config file for the CLI arguments, removing this point of failure, this choice can be (and should be) revisited.
5. Composer dependency downloads will be cached for faster builds using a predefined GH action specifically created for this purpose. The alternative would be to handle the caching manually, which would add three extra steps to the script. Note: Caching works differently between Travis and GH Actions. On GH Actions, once a cache has been created, it can't be updated. It can only be replaced by a new cache with a different key. As the PHP version, the composer.json and a potential composer.lock hash are all part of the key used by the above mentioned action, this difference should not have a significant impact. Ref: https://docs.github.com/en/actions/advanced-guides/caching-dependencies-to-speed-up-workflows
6. The Linting check will display the results inline in the GitHub code view using the cs2pr tool.

Differences with the Travis implementation:

• There is a minor difference in the branch filtering being done for push events. Travis accepted PCRE regexes for the filtering. GH Actions uses glob patterns. The glob patterns now in place match the regexes as closely as possible, but are not an exact match to the "old" patterns. They should be sufficient for our purposes though.
• The toggle for running composer install with or without --ignore-platform-reqs has not been implemented as it is currently unnecessary.
• Linting will now also be executed against PHP 8.1 and 8.2 (nightly), neither of which has yet been released. Linting runs against either of these two PHP versions will be "allowed to fail" for the time being. Note: if any of the "allowed to fail" jobs actually fail, the workflow will show as successfull, but there will still be a red x next to a PR. This is a known issue in GHA: actions/runner#2347 There are work-arounds possible for this, however, the work-arounds would hide failures even more, meaning that chances are they won't be seen until they actually become a problem (no longer allowed to fail), which is too late.

CI: switch to GitHub Actions - step 4: javascript checks

This commit:

• Adds a GH Actions workflow for the Javascript related CI checks.
• Removes all references to that check from the .travis.yml configuration.
• Updates the warning thresholds in grunt/config/eslint.js to reflect the current reality.

Notes:

1. Builds will run on:
   • Select pushes using branch filtering similar to before.
   • All pull requests.
   • When manually triggered. Note: manual triggering of builds has to be explicitly allowed. This is not a feature which is enabled by default.
2. 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.
3. The standard Ubuntu 20 image used by this action comes preloaded with Node, NPM and Yarn, so - in contrast to Travis - those don't need to be set up explicitly via script commands. Ref: https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-README.md
4. The build still uses the setup-node action as it allows for caching of the yarn dependencies for faster builds. As no node-version key is set/passed, the default Node version on the Ubuntu image is used for Node itself. Ref: https://github.com/actions/setup-node
5. Includes a "debug" step which will show the versions of the underlying tooling used, which should come in handy when the build would fail unexpectedly.

Differences with the Travis implementation:

• In Travis, the TRAVIS_NODE_VERSION constant was set to node, which resulted in Node 16 being used. The version shipped with the Ubuntu 20 image is Node 14. Similarly, there are differences in the NPM and Yarn versions used. This has been discussed and as the versions of these tools should not have any effects on the outcome of the grunt check command, this has been deemed acceptable.
• In Travis, the install step always ran a composer install, including for the JS checks. I have determined that this step is not actually needed for the JS check, so it is not included in this script.

Additional observations:

• The yarn install yields two warnings. These were also previously thrown in Travis. These should be looked into separately.

  warning " > eslint-config-yoast@3.0.1" has incorrect peer dependency "eslint-plugin-react@^6.0.0".
  warning " > eslint-plugin-react@7.9.1" has unmet peer dependency "eslint@^3.0.0 || ^4.0.0".

CI: switch to GitHub Actions - step 5: PHP unit tests

This commit:

• Adds a GH Actions workflow for the PHPUnit CI check.
• Removes the, now redundant, .travis.yml configuration.
• Updates the .gitattributes file to reflect the removal of the .travis.yml file.

Notes:

1. Builds will run on:
   • Select pushes using branch filtering similar to before.
   • All pull requests.
   • When manually triggered. Note: manual triggering of builds has to be explicitly allowed. This is not a feature which is enabled by default.
2. 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.
3. The default ini settings used by the setup-php action are based on the php.ini-production configuration. This means that error_reporting=E_ALL & ~E_DEPRECATED & ~E_STRICT, display_errors is set to Off and zend.assertions is set to -1 (= do not compile). For the purposes of CI, especially for linting and testing code, I'd recommend running with zend.assertions=-1,error_reporting=-1anddisplay_errors=Onto ensure **all** PHP notices are shown. Note: the defaults will be changed in the next major ofsetup-phpto be based on thephp.ini-develop` configuration, but that may still be a while off. Refs:
   • shivammathur/setup-php#450
   • shivammathur/setup-php#469
4. While the setup-php action offers the ability to install the PHAR file for PHPUnit, I've elected not to use that option as we need to do a composer install anyway to get the other dependencies, like WP Test Utils.
5. Composer dependency downloads will be cached for faster builds using a predefined GH action specifically created for this purpose. The alternative would be to handle the caching manually, which would add three extra steps to the script. Note: Caching works differently between Travis and GH Actions. On GH Actions, once a cache has been created, it can't be updated. It can only be replaced by a new cache with a different key. As the PHP version, the composer.json and a potential composer.lock hash are all part of the key used by the above mentioned action, this difference should not have a significant impact. Ref: https://docs.github.com/en/actions/advanced-guides/caching-dependencies-to-speed-up-workflows
6. As ACF only contains BrainMonkey based unit tests, we can (and should) use the most appropriate PHPUnit/BrainMonkey/Mockery/etc version for the PHP version the tests are being run on. Most notably, this is actually needed to get the tests running on PHP 8.0 and higher. As there is a committed composer.lock file and the PHPUnit version is locked at PHPUnit 5.x, this means we have to do an on-the-fly update of the PHPUnit version depending on the PHP version of the current build. As we still also want to benefit from the Composer caching which the ramsey/composer-install action sets up, I've done some nifty trickery with the options passed to the composer-install action to get that working.
   • The dependency-versions: "highest" basically changes the command used by the action from composer install to composer update, however we don't want to update all dependencies as run-time dependencies should remain locked at their original version.
   • To that end, I'm passing additional composer-options which will limit the update to just and only the test dependencies.
   • This update also explicitly ignores PHP platform requirements as the composer.json file contains an explicit "php": "5.6.40" platform setting, which would otherwise block the update. Alternatively, the platform requirement could be removed on the fly for CI only.
   • This update is only run for PHP 7.3 and higher, which means that the test runs on PHP 7.3 and higher will be run on PHPUnit 9.x.

Differences with the Travis implementation:

• In addition to the PHP version against which the tests were previously run on Travis, the tests will now also be run against PHP 8.1. Builds against PHP 8.1 will be "allowed to fail" for the time being. Note: if a "allowed to fail" job actually fails, the workflow will show as successful, but there will still be a red x next to a PR. This is a known issue in GHA: actions/runner#2347 There are work-arounds possible for this, however, the work-arounds would hide failures even more, meaning that chances are they won't be seen until they actually become a problem (no longer allowed to fail), which is too late.

Test instructions

These workflows have been extensively tested already and need no further testing.

Aside from the builds run for this PR, you can find the results of various specific tests also on the "Actions" page. For each job, it has been verified that the build(s) will actually show as failed when code has been altered to induce a fail condition.

The commits used to test and demonstrate that the workflows exit as successful and fail as unsuccessful when appropriate, can be examined in this temporary branch: https://github.com/Yoast/yoast-acf-analysis/commits/TEMP/2146981 (That branch will be deleted once this PR has been merged)

[diedexx]

Nice, Thanks @jrfnl!