Repository navigation
Conversation
GitHub's merge queue builds a temporary gh-readonly-queue/* branch and fires the merge_group event; workflows that only trigger on pull_request/push never run there, so required status checks report nothing and every queue entry times out. Add merge_group as a trigger to both workflows so their jobs run when a PR enters the queue.
| branches: [main] | ||
| push: | ||
| branches: [main] | ||
| merge_group: |
There was a problem hiding this comment.
On merge_group every actions/cache step here (and in ci.yml) saves under the gh-readonly-queue ref. No other run can restore from that ref, so each queue entry adds roughly 1-1.5 GB of dead ccache. We're already over the 10 GB quota and main has no ccache-jazzy-* entries left, so this will evict the main and PR caches and push the sanitizer jobs into cold builds. Can we split these into actions/cache/restore plus actions/cache/save with if: github.event_name != 'merge_group', like pixi.yml does with cache-write?
| branches: [main] | ||
| push: | ||
| branches: [main] | ||
| merge_group: |
There was a problem hiding this comment.
On merge_group, build-and-test and jazzy-test save about 0.5 GB of ccache under the gh-readonly-queue ref. The push to main that follows has the same sha but can't read that scope, so it rebuilds from restore-keys and saves the same key again. We're already at 10.1 GB of a 10 GB cap. Can we split those two steps into actions/cache/restore + actions/cache/save, with if: github.event_name != 'merge_group' on the save step?
This branch has not been deployed
2 participants
Pull Request
Summary
mainis getting a merge queue. A queue builds a temporarygh-readonly-queue/*branch and fires themerge_groupevent, and a workflow that triggers only onpull_requestandpushnever runs there, so its checks never report and every queue entry times out.ci.ymlandquality.ymlnow also run onmerge_group.Nothing else changes. The jobs gated on
github.event_name == 'push'(coverage, notify-demos) stay skipped on the queue branch as they are on pull requests, and the clang-tidy job falls back to its full-tree scan there because there is no pull request diff to narrow it to.Issue
No issue. Two
on:blocks, needed before the queue can be enabled.Type
Testing
on:block in each and nothing else.merge_group: types: [checks_requested]).merge_grouprun.Checklist