-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🧪 Make post-gate job chain run on gate success #602
🧪 Make post-gate job chain run on gate success #602
Conversation
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 <[email protected]>
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
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. |
Previously, jobs following the
check
job didn't haveif
conditionalsor 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, whichhas a boolean flag/checkbox for disregarding the testing stage status.
Using it makes the
check
gate pass even when some test matrix jobsfail. It was not obvious that jobs the depend on
check
don'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
if
conditionals to force GitHub Actions CI/CDto only take into account the
check
job result and not itsdependencies by prepending the trick of
always() && needs.check.result == 'success' &&
in front of eachif
conditional in publishing jobs.
Refs:
Co-Authored-By: Pavel Březina [email protected]
ISSUE TYPE
ADDITIONAL INFORMATION
N/A