측정
PR 하나(#1975, head 8c6b052e)가 실제 작업 전 단계에서 만든 체크런 13개입니다.
queued Detect changed scope ← strix.yml
queued Detect changed scope ← security-scan.yml
queued Detect changed scope ← sast-semgrep.yml
queued Detect CodeQL languages
queued Detect Python
queued Admit current pull request head
queued admit-current-head
queued gitleaks (secret scan)
queued required-workflow-bootstrap
queued scan-pr-queue
skipped cancel-closed-pr-runs
skipped cancel-superseded-opencode-review-runs
skipped cancel-superseded-pr-runs
Detect changed scope 가 세 번 있습니다. 세 워크플로가 각각 선언합니다.
grep -rln "Detect changed scope" .github/workflows/
.github/workflows/strix.yml
.github/workflows/security-scan.yml
.github/workflows/sast-semgrep.yml
같은 것을 계산하는 잡 셋이 각각 러너를 하나씩 잡습니다. 검출/입장 계열까지 세면 13개 중 5개가 본 작업 전의 게이트 잡입니다.
왜 이게 지금 비싼가
희소 자원이 러너-분이 아니라 큐 슬롯입니다. 같은 시각 측정입니다.
actions/runs?status=queued total_count 196
디스패치 레인 실측 (#1929) 대기 44분 22초 / 실행 3초
3초짜리 잡도 44분치 슬롯을 씁니다. 그러니 "가벼운 검출 잡"이라는 직관이 여기서는 틀립니다. PR 하나가 본 작업 전에 슬롯 다섯 개를 소비하고, 그 중 셋은 서로 같은 답을 계산합니다.
왜 단순 합치기가 아닌가
중복이 실수가 아니라 규정된 패턴입니다. CLAUDE.md 는 required workflow 에 트리거 수준 필터(paths, branches, types)를 절대 넣지 말고 잡 수준 changed-scope 게이트로 건너뛰라고 못박습니다. 조직 ruleset 이 on: 필터를 버리기 때문입니다. 그리고 실행이 skipped 가 아니라 success 로 끝나도록 출력 의존 if: 가 없는 잡을 하나 남기라고도 합니다.
즉 워크플로가 셋으로 나뉘어 있는 한, 검출 잡도 셋입니다. 워크플로를 합쳐야 검출이 하나가 됩니다 — 하나의 Detect changed scope 가 needs: 로 세 잡을 먹이는 형태로요.
결정이 필요한 지점
합치면 required context 이름이 바뀝니다. .github 는 조직 ruleset 이 아니라 14개 이름 붙은 컨텍스트의 classic branch protection 을 쓰고, 사라진 이름은 영원히 Pending 으로 남습니다. 그 재설정은 소유자 조치입니다.
세 워크플로의 정확한 컨텍스트 이름과 ruleset 파일 목록 영향은 아직 확인하지 않았습니다. 확인 없이 합치면 안 됩니다.
- (가) 세 보안 워크플로를 한 파일로 합치고 검출 잡을 공유. PR 당 슬롯 2개 절약. 컨텍스트 개명이 따라오고 branch protection 재설정이 필요.
- (나) 현행 유지. PR 당 슬롯 3개를 검출에 계속 지출.
이 이슈가 주장하지 않는 것
큐 적체의 주된 원인이라고 말하지 않습니다. 같은 시각 표집에서 최대 점유자는 성공률 0인 CodeQL Scan Dispatch(표집의 39%, #1929)입니다. 이건 그것과 별개의, 더 작고 소유자 조치 없이는 못 고치는 지출입니다.
🤖 Generated with Claude Code
측정
PR 하나(#1975, head
8c6b052e)가 실제 작업 전 단계에서 만든 체크런 13개입니다.Detect changed scope가 세 번 있습니다. 세 워크플로가 각각 선언합니다.같은 것을 계산하는 잡 셋이 각각 러너를 하나씩 잡습니다. 검출/입장 계열까지 세면 13개 중 5개가 본 작업 전의 게이트 잡입니다.
왜 이게 지금 비싼가
희소 자원이 러너-분이 아니라 큐 슬롯입니다. 같은 시각 측정입니다.
3초짜리 잡도 44분치 슬롯을 씁니다. 그러니 "가벼운 검출 잡"이라는 직관이 여기서는 틀립니다. PR 하나가 본 작업 전에 슬롯 다섯 개를 소비하고, 그 중 셋은 서로 같은 답을 계산합니다.
왜 단순 합치기가 아닌가
중복이 실수가 아니라 규정된 패턴입니다.
CLAUDE.md는 required workflow 에 트리거 수준 필터(paths,branches,types)를 절대 넣지 말고 잡 수준changed-scope게이트로 건너뛰라고 못박습니다. 조직 ruleset 이on:필터를 버리기 때문입니다. 그리고 실행이skipped가 아니라success로 끝나도록 출력 의존if:가 없는 잡을 하나 남기라고도 합니다.즉 워크플로가 셋으로 나뉘어 있는 한, 검출 잡도 셋입니다. 워크플로를 합쳐야 검출이 하나가 됩니다 — 하나의
Detect changed scope가needs:로 세 잡을 먹이는 형태로요.결정이 필요한 지점
합치면 required context 이름이 바뀝니다.
.github는 조직 ruleset 이 아니라 14개 이름 붙은 컨텍스트의 classic branch protection 을 쓰고, 사라진 이름은 영원히 Pending 으로 남습니다. 그 재설정은 소유자 조치입니다.세 워크플로의 정확한 컨텍스트 이름과 ruleset 파일 목록 영향은 아직 확인하지 않았습니다. 확인 없이 합치면 안 됩니다.
이 이슈가 주장하지 않는 것
큐 적체의 주된 원인이라고 말하지 않습니다. 같은 시각 표집에서 최대 점유자는 성공률 0인 CodeQL Scan Dispatch(표집의 39%, #1929)입니다. 이건 그것과 별개의, 더 작고 소유자 조치 없이는 못 고치는 지출입니다.
🤖 Generated with Claude Code