[CI] Fix random job cancellations in combined publish workflows#11703
Merged
BDevParity merged 10 commits intomasterfrom Apr 15, 2026
Merged
[CI] Fix random job cancellations in combined publish workflows#11703BDevParity merged 10 commits intomasterfrom
BDevParity merged 10 commits intomasterfrom
Conversation
Replace unreliable `github.event_name == 'workflow_dispatch'` guard with explicit `skip_sync_check` input to prevent redundant check-synchronization calls from colliding on the same concurrency group when called from combined workflows.
alvicsam
approved these changes
Apr 9, 2026
EgorPopelyaev
approved these changes
Apr 9, 2026
EgorPopelyaev
requested changes
Apr 9, 2026
Contributor
EgorPopelyaev
left a comment
There was a problem hiding this comment.
We need to find another way to skip this check, otherwise, the jobs can be triggered separatelly without it
… release safeguards Even when skip_sync_check skips the full check-synchronization workflow, downstream jobs now independently verify repository_owner == RELEASE_ORG and RELEASES_ON == true before proceeding.
2 tasks
Each caller now passes a unique concurrency_suffix so parallel check-synchronization invocations within the same workflow run get distinct concurrency groups and don't cancel each other. Also restores check-synchronization in release-reusable-publish-packages with the concurrency suffix and inline org/killswitch guard. Depends on: paritytech-release/sync-workflows#12
Contributor
|
LGTM, but let's test it before merge |
EgorPopelyaev
approved these changes
Apr 13, 2026
…sions Skipping check-synchronization via skip_sync_check caused GitHub to propagate the skipped-ancestor status through the dependency chain, making all downstream build jobs skip silently. With unique concurrency_suffix values on every check-synchronization call, parallel invocations no longer collide. No need to skip anything.
EgorPopelyaev
approved these changes
Apr 15, 2026
Contributor
|
Review required! Latest push from author must always be reviewed |
paritytech-release-backport-bot Bot
pushed a commit
that referenced
this pull request
Apr 15, 2026
## Summary
- The combined publish workflows (`release-70`, `release-22`) call
multiple sub-workflows that each invoke `check-synchronization.yml`.
That reusable workflow has a concurrency group (`${{ github.repository
}}-${{ github.workflow }}-${{ github.ref }}`) that evaluates to the
**same value** for all callers within a single run, causing GitHub to
randomly cancel competing jobs.
- PR #11631 attempted to fix this with `github.event_name ==
'workflow_dispatch'` guards, but `github.event_name` propagates the
original trigger through `workflow_call` chains, so the guard doesn't
reliably skip the check.
- This PR replaces that guard with an explicit `skip_sync_check` boolean
input. Combined workflows pass `skip_sync_check: true` since they
already run the check at the top level. Standalone dispatches default to
`false`, preserving existing behavior.
- Also removes the redundant `check-synchronization` job from
`release-reusable-publish-packages.yml` (only ever called from workflows
that already perform the check).
Evidence: [4 consecutive failed
attempts](https://github.com/paritytech-release/polkadot-sdk/actions/runs/23787944175)
with different random jobs cancelled each time.
## Issue
- paritytech/release-engineering#291
---------
Co-authored-by: Egor_P <egor@parity.io>
(cherry picked from commit 9f6182f)
|
Successfully created backport PR for |
|
Created backport PR for
Please cherry-pick the changes locally and resolve any conflicts. git fetch origin backport-11703-to-stable2509
git worktree add --checkout .worktree/backport-11703-to-stable2509 backport-11703-to-stable2509
cd .worktree/backport-11703-to-stable2509
git reset --hard HEAD^
git cherry-pick -x 9f6182fe1ef2a4bd2013571396999ddd4044a8ef
git push --force-with-lease |
|
Successfully created backport PR for |
paritytech-release-backport-bot Bot
pushed a commit
that referenced
this pull request
Apr 15, 2026
## Summary
- The combined publish workflows (`release-70`, `release-22`) call
multiple sub-workflows that each invoke `check-synchronization.yml`.
That reusable workflow has a concurrency group (`${{ github.repository
}}-${{ github.workflow }}-${{ github.ref }}`) that evaluates to the
**same value** for all callers within a single run, causing GitHub to
randomly cancel competing jobs.
- PR #11631 attempted to fix this with `github.event_name ==
'workflow_dispatch'` guards, but `github.event_name` propagates the
original trigger through `workflow_call` chains, so the guard doesn't
reliably skip the check.
- This PR replaces that guard with an explicit `skip_sync_check` boolean
input. Combined workflows pass `skip_sync_check: true` since they
already run the check at the top level. Standalone dispatches default to
`false`, preserving existing behavior.
- Also removes the redundant `check-synchronization` job from
`release-reusable-publish-packages.yml` (only ever called from workflows
that already perform the check).
Evidence: [4 consecutive failed
attempts](https://github.com/paritytech-release/polkadot-sdk/actions/runs/23787944175)
with different random jobs cancelled each time.
## Issue
- paritytech/release-engineering#291
---------
Co-authored-by: Egor_P <egor@parity.io>
(cherry picked from commit 9f6182f)
paritytech-release-backport-bot Bot
pushed a commit
that referenced
this pull request
Apr 15, 2026
## Summary
- The combined publish workflows (`release-70`, `release-22`) call
multiple sub-workflows that each invoke `check-synchronization.yml`.
That reusable workflow has a concurrency group (`${{ github.repository
}}-${{ github.workflow }}-${{ github.ref }}`) that evaluates to the
**same value** for all callers within a single run, causing GitHub to
randomly cancel competing jobs.
- PR #11631 attempted to fix this with `github.event_name ==
'workflow_dispatch'` guards, but `github.event_name` propagates the
original trigger through `workflow_call` chains, so the guard doesn't
reliably skip the check.
- This PR replaces that guard with an explicit `skip_sync_check` boolean
input. Combined workflows pass `skip_sync_check: true` since they
already run the check at the top level. Standalone dispatches default to
`false`, preserving existing behavior.
- Also removes the redundant `check-synchronization` job from
`release-reusable-publish-packages.yml` (only ever called from workflows
that already perform the check).
Evidence: [4 consecutive failed
attempts](https://github.com/paritytech-release/polkadot-sdk/actions/runs/23787944175)
with different random jobs cancelled each time.
## Issue
- paritytech/release-engineering#291
---------
Co-authored-by: Egor_P <egor@parity.io>
(cherry picked from commit 9f6182f)
|
Successfully created backport PR for |
EgorPopelyaev
added a commit
that referenced
this pull request
Apr 16, 2026
Backport #11703 into `stable2506` from BDevParity. See the [documentation](https://github.com/paritytech/polkadot-sdk/blob/master/docs/BACKPORT.md) on how to use this bot. <!-- # To be used by other automation, do not modify: original-pr-number: #${pull_number} --> Co-authored-by: BDevParity <bruno.devic@parity.io> Co-authored-by: Egor_P <egor@parity.io>
EgorPopelyaev
pushed a commit
that referenced
this pull request
Apr 16, 2026
Backport #11703 into `stable2509` from BDevParity. See the [documentation](https://github.com/paritytech/polkadot-sdk/blob/master/docs/BACKPORT.md) on how to use this bot. <!-- # To be used by other automation, do not modify: original-pr-number: #${pull_number} --> Co-authored-by: BDevParity <bruno.devic@parity.io>
EgorPopelyaev
added a commit
that referenced
this pull request
Apr 16, 2026
Backport #11703 into `stable2512` from BDevParity. See the [documentation](https://github.com/paritytech/polkadot-sdk/blob/master/docs/BACKPORT.md) on how to use this bot. <!-- # To be used by other automation, do not modify: original-pr-number: #${pull_number} --> Co-authored-by: BDevParity <bruno.devic@parity.io> Co-authored-by: Egor_P <egor@parity.io>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
release-70,release-22) call multiple sub-workflows that each invokecheck-synchronization.yml. That reusable workflow has a concurrency group (${{ github.repository }}-${{ github.workflow }}-${{ github.ref }}) that evaluates to the same value for all callers within a single run, causing GitHub to randomly cancel competing jobs.github.event_name == 'workflow_dispatch'guards, butgithub.event_namepropagates the original trigger throughworkflow_callchains, so the guard doesn't reliably skip the check.skip_sync_checkboolean input. Combined workflows passskip_sync_check: truesince they already run the check at the top level. Standalone dispatches default tofalse, preserving existing behavior.check-synchronizationjob fromrelease-reusable-publish-packages.yml(only ever called from workflows that already perform the check).Evidence: 4 consecutive failed attempts with different random jobs cancelled each time.
Issue