[fivetran-data-model-bot]

Summary

• Applying docs:ready twice in a row starts two generate-docs.yml runs in parallel. Both check out the same commit, so the second one's push gets rejected (fetch first). Its failure step then removes docs:ready and posts a failure status, even though the first run already pushed current docs and CHANGELOG.md.
• Adds a job-level concurrency group per repo + PR, with cancel-in-progress: true. Only the latest run matters, like Buildkite: a new run cancels the one in progress.
• GitHub allows one running job per group, so the new run starts only after the cancelled one has stopped, and it checks out the latest branch. A cancelled run doesn't trigger the if: failure() steps, so the label stays and no failure status is posted.

Real-world repro

dbt_salesforce#93 at 20:51 on 10/30:

• docs:ready was applied twice (20:51:02 and 20:51:16), starting two generate runs on 212414d.
• Run 1 pushed b4751cc at 20:52:23, and the check then posted success.
• Run 2's push was rejected at 20:52:37. Its failure step removed the label at 20:52:39.

Not covered here

check-docs-current.yml can still remove the label when it finishes after you've already applied it. That happens when the check from your own push reports stale (correctly) right after you add docs:ready. That's a separate behavior question: whether the check should remove the label at all, or rely only on the status.

Test plan

• On a package PR, apply docs:ready, remove it, and re-apply it quickly. The first run should show as cancelled, the second should succeed, and the label should stay.

🤖 Generated with Claude Code