Add additional triggers to integration test workflow #124
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The project uses the standard GitHub Actions convention of providing a major version ref. A branch with the format `v<major>` is used for that purpose. These release branches may contain a subset of the history of the default branch. Although most often this would mirror the history on the `main` branch, in some cases it might be beneficial to cherry-pick the commits ready for release to the release branch, excluding other commits that are not yet ready for release. The status of the GitHub Actions workflows should be evaluated before making a release. However, this is not so simple as checking the status of the commit at the tip of the release branch. The reason is that, for the sake of efficiency, the workflows are configured to run only when the processes are relevant to the trigger event (e.g., no need to run unit tests for a change to the readme). In the case of the default branch, you can simply set the workflow runs filter to that branch and then check the result of the latest run of each workflow of interest. However, that was not possible to do with the release branch since it might be that the workflow was never run in that branch. The status of the latest run of the workflow in the default branch might not match the status for the release branch if the release branch does not contain the full history. For this reason, it will be helpful to trigger all relevant workflows on the creation of a release branch. This will ensure that each of those workflows will always have at least one run in the release branch. Subsequent commits pushed to the branch can run based on their usual trigger filters and the status of the latest run of each workflow in the branch will provide an accurate indication of the state of that branch. Branches are created for purposes other than releases, most notably feature branches to stage work for a pull request. Because the collection of workflows in a Tooling project are often very comprehensive, it would not be convenient or efficient to run them on the creation of every feature branch. Unfortunately, GitHub Actions does not support filters on the `create` event of branch creation like it does for the `push` and `pull_request` events. There is support for a `branches` filter of the `push` event, but that filter is an AND to the `paths` filter and this application requires an OR. For this reason, the workflows must be triggered by the creation of any branch. The unwanted job runs are prevented by adding a `run-determination` job with the branch filter handled by Bash commands. The other jobs of the workflow use this `run-determination` job as a dependency, only running when it indicates they should via a job output. Because this minimal `run-determination` job runs very quickly, it is roughly equivalent to the workflow having been skipped entirely for non-release branch creations. This approach has been in use for some time already in the versioned "Deploy Website" workflows. Previously the regular expression used to identify release branches used the `<major>.<minor>.x` format that is standard in non-action tooling projects, but wrong for this project.
The project uses the standard GitHub Actions convention of providing a major version ref. A branch is used for that purpose. These release branches may contain a subset of the history of the default branch. Although most often this would mirror the history on the `main` branch, in some cases it might be beneficial to cherry-pick the commits ready for release to the release branch, excluding other commits that are not yet ready for release. The status of the GitHub Actions workflows should be evaluated before making a release. However, this is not so simple as checking the status of the commit at the tip of the release branch. The reason is that, for the sake of efficiency, the workflows are configured to run only when the processes are relevant to the trigger event (e.g., no need to run unit tests for a change to the readme). In the case of the default branch, you can simply set the workflow runs filter to that branch and then check the result of the latest run of each workflow of interest. However, that was not possible to do with the release branch since it might be that the workflow was never run in that branch. The status of the latest run of the workflow in the default branch might not match the status for the release branch if the release branch does not contain the full history. For this reason, it will be helpful to trigger all relevant workflows on the creation of a release branch. This will ensure that each of those workflows will always have at least one run in the release branch. Subsequent commits pushed to the branch can run based on their usual trigger filters and the status of the latest run of each workflow in the branch will provide an accurate indication of the state of that branch. Branches are created for purposes other than releases, most notably feature branches to stage work for a pull request. Because the collection of workflows in a Tooling project are often very comprehensive, it would not be convenient or efficient to run them on the creation of every feature branch. Unfortunately, GitHub Actions does not support filters on the `create` event of branch creation like it does for the `push` and `pull_request` events. There is support for a `branches` filter of the `push` event, but that filter is an AND to the `paths` filter and this application requires an OR. For this reason, the workflows must be triggered by the creation of any branch. The unwanted job runs are prevented by adding a `run-determination` job with the branch filter handled by Bash commands. The other jobs of the workflow use this `run-determination` job as a dependency, only running when it indicates they should via a job output. Because this minimal `run-determination` job runs very quickly, it is roughly equivalent to the workflow having been skipped entirely for non-release branch creations.
The project infrastructure may be broken by changes to the external dependencies (e.g., GitHub Actions runner changes, runner machine OS/environment updates, action releases, tool releases). If this breakage is not caught and fixed quickly by the maintainer, it may cause confusion to the contributors whose contributions trigger a spurious workflow run failure. Monitoring for breakage can be done by periodically triggering a workflow run.
These allow the maintainer to trigger a workflow run after a relevant external change.
per1234
added
type: enhancement
Codecov ReportPatch and project coverage have no change.
Additional details and impacted files@@ Coverage Diff @@
## main #124 +/- ##
=======================================
Coverage 99.81% 99.81%
=======================================
Files 2 2
Lines 1610 1610
=======================================
Hits 1607 1607
Misses 3 3 Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.