-
-
Couldn't load subscription status.
- Fork 4
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: falseHow 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_dispatchorrepository_dispatch(upcoming), should never be cancelled and should always be allowed to finish.