-
-
Notifications
You must be signed in to change notification settings - Fork 1
Open
Description
The publish-wiki
workflow currently has the following concurrency setting, but this is not working as intended:
# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
group: "publish-wiki"
cancel-in-progress: false
How it should ideally work:
- PR builds should be cancelled on a new push in favour of building the newly pushed version.
- However, for pushes to
main
, every single push should be build in the correct order and if there are multiple pushes, subsequent builds should be queued.
I.e. if three PRs are merged quickly after each other....- the build for the commit merged from PR 1 should run first and be allowed to finish;
- then the build for the commit merged from PR 2 should run and be allowed to finish;
- next the build for the commit merged from PR 3 should run and be allowed to finish;
- Builds triggered via
workflow_dispatch
orrepository_dispatch
(upcoming), should never be cancelled and should always be allowed to finish.