What
Every content push to main starts two Pages deploys, and the first is almost always cancelled:
push to main matches pages.yml's paths: filter and starts a deploy.release.yml bumps the version ([skip ci] commit), then runs gh workflow run pages.yml --ref main (release.yml:183-187).concurrency: { group: pages, cancel-in-progress: true } cancels run 1 in favour of run 2.
Of the last 20 pages.yml runs: 8 push runs cancelled, 1 push run succeeded, 11 workflow_dispatch runs succeeded.
The site ends up correct, with the version bump included, so this is waste, not breakage: one runner job per release cancelled partway through the build.
Options
- Keep the
push trigger only for pushes that will not produce a release (docs: / chore: subjects). That is awkward to express in paths:.
- Drop the
push trigger and rely on the release dispatch plus manual workflow_dispatch. Risk: a non-release content push would not deploy.
- Accept it and document why the cancelled runs are expected.
Low priority. Found during the Pages review in #208.
What
Every content push to
mainstarts two Pages deploys, and the first is almost always cancelled:pushtomainmatchespages.yml'spaths:filter and starts a deploy.release.ymlbumps the version ([skip ci]commit), then runsgh workflow run pages.yml --ref main(release.yml:183-187).concurrency: { group: pages, cancel-in-progress: true }cancels run 1 in favour of run 2.Of the last 20
pages.ymlruns: 8pushruns cancelled, 1pushrun succeeded, 11workflow_dispatchruns succeeded.The site ends up correct, with the version bump included, so this is waste, not breakage: one runner job per release cancelled partway through the build.
Options
pushtrigger only for pushes that will not produce a release (docs:/chore:subjects). That is awkward to express inpaths:.pushtrigger and rely on the release dispatch plus manualworkflow_dispatch. Risk: a non-release content push would not deploy.Low priority. Found during the Pages review in #208.