ci(concurrency): scope noema/strix/opencode workflows by PR number - #1787
ci(concurrency): scope noema/strix/opencode workflows by PR number#1787seonghobae wants to merge 11 commits into
Conversation
…s (minute 44) callers - Thin hourly callers delegate to pr-review-fix-scheduler with develop bases, single dispatch, and two-hour same-head retry floors. - appguardrail fills its long-reserved roster slot; macos_utility_packs takes a fresh non-colliding minute. - Doctoring records activation prerequisites incl. the OPENCODE_REPOSITORY_DISPATCH_TARGETS allowlist entries (set at org level in the same change window) with APA 7th references. - Focused contract tests mirror the established trio; quality gate pull/push/compileall path blocks track all six files.
…provider base URL resolved_llm_api_base_for_model had cross-provider handling only for github_models/* fallbacks. When the primary provider was nvidia_nim (or any provider that sets LLM_API_BASE), openai-direct/gpt-5.4 fallback attempts inherited the NVIDIA inference endpoint while carrying the OpenAI key, so litellm posted to the wrong host and every attempt died with 'Error: 404 page not found' (STRIX_PROVIDER_UNAVAILABLE). Direct OpenAI attempts now resolve to no custom base so litellm routes to api.openai.com by default (#1327).
|
Warning Review limit reachedNext included review available in 31 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: Organization UI Review profile: CHILL Plan: Team Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (37)
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 |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| github.event.client_payload.target_repository || github.repository }}-${{ | ||
| github.event.client_payload.pr_number && format('pr-{0}', github.event.client_payload.pr_number) || | ||
| github.run_id }} | ||
| group: ${{ github.workflow }}-${{ github.repository }}-${{ github.event.client_payload.pr_number || github.event.pull_request.number || github.event.workflow_run.pull_requests[0].number }} |
There was a problem hiding this comment.
🔴 Review dispatches for different repos with the same PR number cancel each other
For repository_dispatch, github.repository is always the central .github repo, and the group no longer includes client_payload.target_repository. Two target repos reviewing the same PR number now share one group, so cancel-in-progress kills the earlier review.
| group: ${{ github.workflow }}-${{ github.repository }}-${{ github.event.client_payload.pr_number || github.event.pull_request.number || github.event.workflow_run.pull_requests[0].number }} | |
| group: ${{ github.workflow }}-${{ github.event.client_payload.target_repository || github.repository }}-${{ github.event.client_payload.pr_number || github.run_id }} |
Was this helpful? React with 👍 or 👎 to provide feedback.
| # PR-number scope keeps the queue on the current HEAD. | ||
| group: ${{ github.workflow }}-${{ github.repository }}-${{ github.event.pull_request.number || github.event.client_payload.pr_number || github.event.workflow_run.pull_requests[0].number }} |
There was a problem hiding this comment.
🔴 Strix scans on different branches and the weekly schedule cancel each other
Strix has no workflow_run trigger, so push and schedule runs leave every number term empty and share the constant group <workflow>-<repo>-. Pushes to main, develop, and master and the weekly scan then cancel each other, and a merge-time strix-scan dispatch can cancel the required pull_request_target run for the same PR.
Prompt for agents
The new concurrency group drops github.event_name and github.ref. strix.yml has no workflow_run trigger, so the github.event.workflow_run.pull_requests[0].number term is always empty. For push and schedule events (and any event without a PR number) the group collapses to a single constant string per repository, so pushes to different protected branches and the weekly scheduled scan all cancel each other under cancel-in-progress: true. Separately, merging pull_request_target and repository_dispatch into the same PR-number group re-introduces the exact problem the removed comment warned about: a default-branch strix-scan retry can cancel the required pull_request_target Strix context read by branch protection. Restore an event-class and/or github.ref (or github.run_id) fallback so non-PR events and different event classes do not share one group.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
|
||
| concurrency: | ||
| group: python-security-${{ github.event.pull_request.base.repo.full_name || github.repository }}-${{ github.event.pull_request.number || github.ref }} | ||
| group: ${{ github.workflow }}-${{ github.repository }}-${{ github.event.pull_request.number }} |
There was a problem hiding this comment.
🔴 Push and scheduled security scans across branches cancel one another
The group dropped its github.ref fallback, so every non-PR event (push to main, master, or develop, the weekly schedule, and repository_dispatch) resolves to the constant <workflow>-<repo>-. With cancel-in-progress they share one group and cancel each other. Identical regression in secret-scan and sast-semgrep.
| group: ${{ github.workflow }}-${{ github.repository }}-${{ github.event.pull_request.number }} | |
| group: ${{ github.workflow }}-${{ github.repository }}-${{ github.event.pull_request.number || github.ref }} |
Was this helpful? React with 👍 or 👎 to provide feedback.
| group: ${{ github.workflow }}-${{ github.repository }}-${{ github.event.pull_request.number }} | ||
| cancel-in-progress: true |
There was a problem hiding this comment.
🔴 Cloudflare apply can be cancelled mid-reconcile by a later run
For push and repository_dispatch there is no PR number, so every such run shares the constant group, and cancel-in-progress was flipped from false to true. A push dry-run or a second apply now cancels an in-flight mode=apply reconcile, which can leave DNS records partially written.
| group: ${{ github.workflow }}-${{ github.repository }}-${{ github.event.pull_request.number }} | |
| cancel-in-progress: true | |
| group: ${{ github.workflow }}-${{ github.repository }}-${{ github.event.pull_request.number || github.ref }} | |
| cancel-in-progress: false |
Was this helpful? React with 👍 or 👎 to provide feedback.
| github.event_name == 'workflow_run' && github.event.workflow_run.pull_requests[0].number && format('pr-{0}', github.event.workflow_run.pull_requests[0].number) || | ||
| github.event_name == 'repository_dispatch' && github.event.client_payload.pr_number || | ||
| github.run_id }} | ||
| group: ${{ github.workflow }}-${{ github.repository }}-${{ github.event.pull_request.number || github.event.client_payload.pr_number || github.event.workflow_run.pull_requests[0].number }} |
There was a problem hiding this comment.
🔍 Noema review may cancel across event types for the same PR
The old group included github.event_name; the new one merges pull_request_target, workflow_run, and repository_dispatch for a PR into one group. A retry dispatch or workflow_run completion can cancel an in-progress required pull_request_target review. Additionally, workflow_run events with an empty pull_requests array leave every number term empty and collapse to the constant <workflow>-<repo>- group.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
|
||
| concurrency: | ||
| group: sbom-generation-${{ github.event.pull_request.base.repo.full_name || github.repository }}-${{ github.event.pull_request.number || github.event.release.tag_name || github.ref }} | ||
| group: ${{ github.workflow }}-${{ github.repository }}-${{ github.event.pull_request.number }} |
There was a problem hiding this comment.
🔍 Concurrent releases cancel each other's SBOM upload
Release events carry no PR number, so the group collapses to the constant <workflow>-<repo>- after the release.tag_name fallback was removed. Two releases published close together share it, and cancel-in-progress aborts the earlier SBOM and release-asset upload.
Was this helpful? React with 👍 or 👎 to provide feedback.
| contents: read | ||
|
|
||
| concurrency: | ||
| group: ${{ github.workflow }}-${{ github.repository }}-${{ github.event.pull_request.number || github.event.workflow_call.head_repository.full_name || github.run_id }} |
There was a problem hiding this comment.
📝 Info: deploy-pages concurrency references a non-existent context property
github.event.workflow_call.head_repository.full_name is not a real context property, so it always resolves empty and the group falls through to github.run_id. Harmless because run_id makes each call unique, but the middle term never contributes.
Was this helpful? React with 👍 or 👎 to provide feedback.
| group: ${{ github.workflow }}-${{ github.repository }}-${{ github.event.pull_request.number || github.event.workflow_run.pull_requests[0].number || inputs.pr_number || github.event.client_payload.pr_number || github.run_id }} | ||
| cancel-in-progress: true |
There was a problem hiding this comment.
🔍 Merge scheduler cancel-in-progress made unconditional
cancel-in-progress is now always true, where the old key excluded schedule and org-sweep runs. The retained github.run_id fallback gives those events unique groups, so behavior is preserved. Confirm that repository_dispatch runs with a pr_number for different target repos do not collide, since github.repository is the constant .github and the old key included target_repository.
Was this helpful? React with 👍 or 👎 to provide feedback.
병합 반대 — 여러 파일에서 오늘 이미 고친 설계를 되돌리고, 실제 운영 위험을 새로 만듭니다전체 diff(~30개 워크플로우 파일)를 직접 읽어봤습니다. 1.
|
|
추가로 하나 더: 방금(.github#1788, #1750) |
…catch The ROPC config fix (79fe43d) exposed a real bug it was masking: password registration created accounts with no way to authenticate once Direct Access Grants was off. Fixed (44f0cb9): endpoint fails closed behind a flippable module constant, validate_realm.py now guards against a silent re-enable, ADR-0015 correction added. Also recorded independently confirming a peer's catch that .github#1787 (stale, pre-dates the already-landed noema-review.yml concurrency-deadlock fix) would have reverted it if merged -- now in draft pending rebase. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Close (delta-none) — 결론 공유두 세션이 각자 독립적으로 이 PR이 건드리는 모든 파일을 검증한 결과, 예외 없이 동일한 결론에 도달했습니다: main은 이미 이 PR이 하려는 일(같은 PR의 구형 실행만 취소)을 각 파일의 실제 트리거 형태에 맞게 더 올바르게 구현하고 있고, 이 PR은 그걸 되돌리는 순수 회귀입니다. 확인된 파일:
이 PR에 담긴 유일한 실질 아이디어(workflow-repository-PR번호 리터럴 형식)는 main에 이미 실질적으로(더 정확한 형태로) 반영돼 있습니다. 되살릴 unlanded delta가 없다고 판단해 org의 repair-not-close 원칙(delta 없음/악성 변경/완전 승계에만 close 허용) 중 'delta 없음'에 해당한다고 보고 close합니다. 브랜치는 남겨두니 혹시 다른 관점의 delta가 있다고 판단되면 reopen 해주세요. |
…close Devin's third pass on keyverse#128 found the OpenAPI schema still promised 201-only, and the disable lacked a changelog/operability/doctoring record. Fixed (86de970). Also caught and self-corrected a citation error before committing: had drafted named individual RFC editors for RFC 9700/10017, realized RFC 10017 postdates any available verification and the RFC 9700 author list wasn't independently confirmable either, replaced both with organizational-author citations. Recorded .github#1787's resolution: two peer sessions cross-checked all 8 touched files independently, found the same "pure revert of already-correct work" pattern in every one, closed under the delta-none exception. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
1 participant
변경 요약\n- noema-review, strix, opencode-review-dispatch 워크플로우의 concurrency 그룹에서 run_id 폴백을 제거\n- 그룹 형식을 기준으로 통일\n- 동일 PR push/재분배 시 구형 실행이 같은 그룹에서 cancel-in-progress 되도록 정합화\n\n요구사항 항목 13(동일 PR 재실행 정합성) 및 전체 동시성 규칙의 핵심 워크플로우부터 반영.