chore(ci): preserve generated concurrency proposal under canonical owners - #1624
chore(ci): preserve generated concurrency proposal under canonical owners#1624seonghobae wants to merge 7 commits into
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Warning Review limit reachedNext included review available in 46 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (9)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
seonghobae
changed the title
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: aeaff9730c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if: github.event_name == 'push' && startsWith(github.ref, 'refs/tags/v') | ||
| # 릴리스 발행은 취소하지 않고 직렬화한다. 태그별 독립 큐. | ||
| concurrency: | ||
| group: docker-publish-release-${{ github.repository }}-${{ github.ref }} |
There was a problem hiding this comment.
On every tag release, all three publish_images matrix children resolve this job-level group to the same value. GitHub retains at most one running and one pending item per concurrency group, replacing an existing pending item when another is queued even when cancel-in-progress is false (GitHub concurrency documentation); while the first image builds, a later matrix child can therefore cancel another, leaving at least one of backend, naruon, or frontend unpublished and preventing the dependent deployment path from proceeding. Remove this job-level concurrency block because the workflow-level group already scopes the release run.
Useful? React with 👍 / 👎.
| group: mail-smoke-${{ github.repository }} | ||
| cancel-in-progress: false |
There was a problem hiding this comment.
When three manual smoke dispatches overlap, this shared group keeps the active run and only the newest pending run; GitHub cancels the previously pending run despite cancel-in-progress: false (GitHub concurrency documentation). That contradicts the stated no-cancellation behavior and discards a requested smoke execution, so rely on the self-hosted runner's queue or use a queueing mechanism that preserves every dispatch.
Useful? React with 👍 / 👎.
| group: docker-publish-${{ github.repository }}-${{ github.event.pull_request.number || github.ref }} | ||
| cancel-in-progress: true |
There was a problem hiding this comment.
If another workflow run for the same tag/ref starts while a release is active—for example, after correcting and re-pushing a tag—this workflow-level cancel-in-progress: true cancels the older run before the job-level false setting can protect publish_images (GitHub concurrency documentation). Because cancellation can occur after only some component images were pushed, the registry can be left with a partial release; make cancellation conditional on pull-request events or use separate workflow-level policies for validation and publishing.
Useful? React with 👍 / 👎.
검증 보고 (자율 루프)
|
실패 분석 (자율 루프)
|
정정 (자율 루프)
|
1 participant
Current authority — 2026-09-09
develop@042b0c70531b229af3acbd0421a2f23098d848b3aeaff9730c8387c5ded10b25576c1c89cd798231e17e87a51f364147a431a4f31b6230f62f71a692Why the generated source is not an active CI owner
The generated lineage changed seven workflow surfaces plus frontend dependency manifests in one PR. Those surfaces already have active, narrower owner lanes with stronger invariants:
cancel-in-progress: truegroup would collapse that distinction.queue: maxcontract under evaluation in fix(ci): serialize Docker release image sets #1621.cancel-in-progress: falsegroup omitsqueue: max, so GitHub's default one-pending replacement semantics can discard an already-pending requested smoke.e8a54fc5156ac3ffbb79bc8418c5125d7dcdea60; broader dependency successor chore(deps): bump the frontend-npm group across 1 directory with 14 updates #1459. The generated dependency bump duplicates their manifest/lock delta but does not carry fix(deps): patch frontend audit security floors #1623's structural lock regression or its RED→GREEN evidence.The original claim that seven local workflows could be normalized to one
{workflow}-{repository}-{PR}pattern is therefore too coarse. Cancellation generation, bounded pending queues, manual reruns, publication atomicity and destination-specific side effects are domain-specific invariants, not one uniform string-format concern.Non-force ownership repair
Ordinary two-parent commit
e17e87a51f364147a431a4f31b6230f62f71a692preserves generated predecessoraeaff973...as first-parent provenance, adopts protecteddevelop@042b0c...as the second parent, and points to protected tree8fde14381aaa430eeaaf61151dab6f6800127cd3. The branch advanced withforce=false; no destructive rebase or history deletion occurred.Fresh protected-base comparison is ahead-only with zero changed files. The generated hypotheses remain in ancestry for each canonical owner to evaluate, but this PR no longer competes for workflow, dependency, lockfile or release-governance source ownership.
Succession boundary
Do not merge this provenance PR. Keep it open as provenance until the canonical owner lanes above normally integrate or explicitly reject the corresponding hypotheses, and a protected-tree audit proves every valid concurrency/security intent is either inherited or deliberately rejected with evidence. Only then may zero-delta closure be justified as complete succession/rejection.
Historical checks/reviews from
aeaff973...do not transfer toe17e87a...; this zero-delta provenance head is not an alternate merge candidate.No force-push, destructive rebase, self-approval, dummy/no-op requeue, synthetic status, competing workflow/dependency source write, review fabrication/dismissal, admin bypass, central-workflow copy, authorization widening, or gate weakening.