ci: Testing: make a trivial documentation-related edit

[jayaddison]

Currently, the following behaviours are configured for GitHub Actions pull request checks in this repository:

• Documentation-related commits (Markdown files, CODEOWNERS, the pull request template, and .editorconfig files) in pull requests succeed.
• Non-documetation-related commits in pull requests fail.

These are configured using the GitHub Actions paths and paths-ignore feature.

Each documentation-related job (e.g. Check perl) has a duplicate non-documentation job with exactly the same name.

This implements a GitHub Actions required-statuses workaround described at: https://github.com/orgs/community/discussions/49124#discussioncomment-5209069

The purpose of this pull request is to find out whether that workaround remains valid. If so, it may provide a simpler solution than using a custom/third-party GitHub Actions action.

Questions:

• What happens when a pull request contains both documentation and non-documentation modifications?
• If we were to use this mechanism, is there a way that we could ensure that the inverted and non-inverted path configurations stay in-sync?

[jayaddison]

What happens when a pull request contains both documentation and non-documentation modifications?

Commit 88c3010 examines this, by merging both this documentation-related pull request (#1) and a corresponding NON-documentation-related pull request (#2).

The answer is that checks related to both workflows (pull_request.yml and pull_request_inverted.yml) are run. For each GitHub Actions required status check, success from one out of the two checks is insufficient to allow merge of the pull request. This seems to indicate that both must succeed.

[jayaddison]

If we were to use this mechanism, is there a way that we could ensure that the inverted and non-inverted path configurations stay in-sync?

What happens when a pull request contains both documentation and non-documentation modifications?

The answer is that checks related to both workflows (pull_request.yml and pull_request_inverted.yml) are run. For each GitHub Actions required status check, success from one out of the two checks is insufficient to allow merge of the pull request. This seems to indicate that both must succeed.

In combination, does this mean that the inverted workflow could have a paths: * wildcard? Meaning that it would always succeed -- fulfilling the GitHub Actions required status check for PRs that do not modify specific filesets -- but also ensuring that if those specific fileset checks do fail, the relevant PRs are still blocked from merge?