🧪 Make post-gate job chain run on gate success #602
Merged
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
Previously, jobs following the `check` job didn't have `if` conditionals or the existing expressions didn't use the status check functions. Those jobs are responsible for the finishing steps of the release automation. They used to work when the entire parent job tree was successful. The release automation is triggered by the `workflow_dispatch` event, which has a boolean flag/checkbox for disregarding the testing stage status. Using it makes the `check` gate pass even when some test matrix jobs fail. It was not obvious that jobs the depend on `check` don't run if any of the parent chain jobs fail. Not by default, so they were being skipped for no obvious reason. This patch updates said `if` conditionals to force GitHub Actions CI/CD to only take into account the `check` job result and not its dependencies by prepending the trick of `always() && needs.check.result == 'success' &&` in front of each `if` conditional in publishing jobs. Refs: * actions/runner#2205 (comment) * https://github.com/orgs/community/discussions/45058#discussioncomment-7465690 * https://docs.github.com/en/actions/learn-github-actions/expressions#status-check-functions Co-Authored-By: Pavel Březina <pbrezina@redhat.com>
This patch refactors the conditionals with hardcoded job IDs into universal name-agnostic checks. Refs: * https://github.com/orgs/community/discussions/45058#discussioncomment-8470000
GitHub recommends avoiding `always()` where possible. Relying on the cancellation check makes in possible to skip publishing more cleanly. Refs: * https://docs.github.com/en/actions/learn-github-actions/expressions#always * https://docs.github.com/en/actions/managing-workflow-runs/canceling-a-workflow#steps-github-takes-to-cancel-a-workflow-run
psf-chronographer
bot
added
the
bot:chronographer:provided
|
Congratulations! One of the builds has completed. 🍾 You can install the built RPMs by following these steps:
Please note that the RPMs should be used only in a testing environment. |
|
I reverted 30a9da5 because https://github.com/ansible/pylibssh/actions/runs/9414210260 revealed that the workflow seems to go into the canceled state after ignored failures anyway so it's not possible to rely on this check. |
|
I also reverted f5597a0 for the same reason — I probably missed something in the generalization example, so I will have to get back to trying it out later. |
|
The workflow is now functional in YOLO mode: https://github.com/ansible/pylibssh/actions/runs/9419572873. Finally. |
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.
Previously, jobs following the
checkjob didn't haveifconditionalsor the existing expressions didn't use the status check functions. Those
jobs are responsible for the finishing steps of the release automation.
They used to work when the entire parent job tree was successful. The
release automation is triggered by the
workflow_dispatchevent, whichhas a boolean flag/checkbox for disregarding the testing stage status.
Using it makes the
checkgate pass even when some test matrix jobsfail. It was not obvious that jobs the depend on
checkdon't run ifany of the parent chain jobs fail. Not by default, so they were being
skipped for no obvious reason.
This patch updates said
ifconditionals to force GitHub Actions CI/CDto only take into account the
checkjob result and not itsdependencies by prepending the trick of
always() && needs.check.result == 'success' &&in front of eachifconditional in publishing jobs.
Refs:
Co-Authored-By: Pavel Březina pbrezina@redhat.com
ISSUE TYPE
ADDITIONAL INFORMATION
N/A