Comment workflows and Mergify config a bit better #10359
Conversation
| @@ -79,6 +79,7 @@ jobs: | |||
| # This way we can use it exclusively in branch protection rules | |||
| # and abstract away the concrete jobs of the workflow, including their names | |||
| bootstrap-post-job: | |||
| # This conditional overrides job cancellation | |||
There was a problem hiding this comment.
Would be good to hint why we want this override.
There was a problem hiding this comment.
I'll do that when I figure it out. 🙃 (There's at least one place where the comment asks why we're doing it there; based on GHA docs, it seems inappropriate.)
There was a problem hiding this comment.
BTW, best I can figure is that it's used in jobs that are marked "required" in branch protection rules and are part of the documentation-skip hack. Except that
- it seems redundant, since cancellation of the job should already fail the required post-job;
- there's those few places that aren't part of branch protection or the doc-skip hack and don't seem to gain anything at all from running on cancellation, notably the one in
validate.ymlthat dumps the GHCup configuration.
| @@ -145,6 +145,7 @@ jobs: | |||
| run: make doc/buildinfo-fields-reference.rst | |||
| - name: Cache dependencies | |||
| uses: actions/cache/save@v4 | |||
| # 'always()' here overrides job cancellation | |||
There was a problem hiding this comment.
Looks clumsy that the same thing is phrased differently than in bootstrap.yml
There was a problem hiding this comment.
Still sorting out how best to put it, and addition of above about why it's wanted. These will all change, probably by explaining it in one place and referencing it in the others.
geekosaur
force-pushed
the
mergify-gha-comments
branch
from
3b32207
to
fd9ca1f
Compare
If you have any "favorite" confusing places in the workflows or Mergify config, please comment on them here so I can try to do something about them. Also, I need some clarification myself, in particular on why we're redundantly using
always()in a number of places and why it seems to be important to use it on doc-skip post jobs when cancellation will correctly fail the workflow and post-job anyway.Template B: This PR does not modify behaviour or interface
E.g. the PR only touches documentation or tests, does refactorings, etc.
Include the following checklist in your PR:
[ ] Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).it's just comments, not worth it unless we think it'll lead to merge conflicts later