Separate nightly and development build concurrency
Added the caller event type to the reusable backend workflow's concurrency key, separating scheduled and push runs while preserving cancellation of stale pushes.
apache/seatunnel · #12467
CI orchestration fix
SeaTunnel nightly validation and development push builds no longer cancel each other simply because both run against the dev branch.
Problem
The nightly workflow and dev push workflow both called the same reusable backend workflow on refs/heads/dev. Its shared concurrency group omitted the caller event, so whichever run started later cancelled the other despite the nightly caller disabling cancellation in its own outer group.
Approach
Includes github.event_name in the reusable workflow's concurrency key. Dev pushes now use a backend-push group and nightlies use a backend-schedule group, while multiple pushes to the same branch continue to cancel stale push runs.
Impact and scope
- Stops unrelated scheduled and post-merge validation runs from starving each other.
- Preserves the intended fast-feedback behavior where a newer push supersedes an older push build.
- Allows nightly failures and duration data to complete, making regressions and timeout-budget problems observable before they surface on unrelated pull requests.
- Addresses the exact shared-group root cause with one workflow-key change rather than disabling cancellation globally.
Validation
- Historical run analysis identified 10 nightlies cancelled by dev pushes and 17 dev push builds cancelled around nightly startup during the reviewed period.
- actionlint 1.7.7 reported no findings, the YAML parsed successfully, and CI-scope checks confirmed the workflow-only change remains lightweight.
- An Apache SeaTunnel member approved the authored change; all four current hosted checks pass. Nightly job timeout sizing remains a separate follow-up.