ci: coverage 상시 red 해소 — codecov 업로드 실패를 비치명으로

[Jun025]

티켓: rustjava-coverage-workflow-codecov-token-red · 발원: PR #11 게이트② 검수 §8 후속 2번

근인 — ★추정이 아니라 실측으로 확정했다

coverage 는 보고를 시작한 이래 한 번도 초록인 적이 없다.

측정	값
gh run list --workflow coverage.yml --limit 60	24건 반환(요청 60 ⇒ 절단 아님)
conclusion 분포	★**failure 24 / success 0**
기간	2026-07-22 ~ 2026-08-17
★실패 스텝(24건 전수 조회)	★**Upload to codecov.io 24 / 그 외 0**

원인은 시크릿 부재 하나다:

gh secret list -R Jun025/RustJava          # rc=0, 출력 없음 (시크릿 0건)
gh secret list -R Jun025/RustJava --app dependabot   # rc=0, 출력 없음

★이 저장소는 fork 다(isFork: true). fork 는 upstream 의 시크릿을 상속하지 않는다.
그래서 token: ${{ secrets.CODECOV_TOKEN }} 이 빈 문자열로 전개되고, 업로더 로그가 그대로 말한다:

->  Token length: 0
info -- Found 1 coverage files to report
info -- > /home/runner/work/RustJava/RustJava/lcov.info
error -- Upload queued for processing failed: {"message":"Token required - not valid tokenless upload"}
==> Failed to run upload-coverage
##[error]Process completed with exit code 1.

fail_ci_if_error: true 가 이 업로드 실패를 job 실패로 승격시켜 왔다.

★커버리지 측정 자체는 내내 성공하고 있었다 — 스텝별 결과: Generate code coverage success ·
Upload to codecov.io failure. 즉 red 가 가리킨 것은 코드가 아니라 발행 경로였다.

처방 — ⒝ fail_ci_if_error: false

⒜ CODECOV_TOKEN 주입은 ★human-step 이다 — 시크릿이 존재하지 않고(위 실측), 발급·등재는 사람 몫이라
이 회차에서 할 수 없다. 게다가 fork 용 토큰은 별도 codecov 프로젝트 등록이 선행돼야 한다.
⇒ ⒝를 택하고 ⒜는 사람 몫으로 남긴다(주석과 아래 «되돌리는 법»에 명시).

★무엇을 잃는가

잃는 것: codecov 업로드가 실패해도 CI 가 빨개지지 않는다. 토큰을 나중에 넣은 뒤 그것이 만료·오설정 되면
조용히 데이터가 안 쌓인다.

그 대가를 줄인 방법:

1. ★오류가 사라지지 않는다 — 비치명이 됐을 뿐 문구는 스텝 로그에 그대로 찍힌다. 초록 run 실측:

   error -- Upload queued for processing failed: {"message":"Token required - not valid tokenless upload"}
   ##[end-action ... outcome=success;conclusion=success]
   

2. 주석에 근인·복구법을 박았다 — 다음 사람이 로그를 보고 「왜 초록인데 에러가 있지」를 되짚을 수 있게.
3. 현실적 하한: 토큰이 없던 지금까지도 codecov 에 데이터가 쌓인 적이 없다. 잃을 데이터가 아직 없다.

★red 를 «삼키지» 않는가 — 삼키지 않는다

근거	실측
구조	Generate code coverage 는 별도 run: 스텝이고 fail_ci_if_error 는 codecov-action 의 입력일 뿐이라 무관하다. grep -F continue-on-error .github/workflows/coverage.yml → rc=1(부재) ⇒ 그 스텝이 실패하면 job 은 여전히 red
이력	24건 전수에서 실패 스텝은 언제나 upload 하나였다 ⇒ ★지금까지 이 플래그가 삼켰을 «진짜 red» 는 0건
실증	초록 run 의 Generate code coverage 가 전체 테스트를 돌렸다(145 passed; 0 failed 등). 테스트가 깨지면 cargo llvm-cov rc≠0 → 스텝 실패 → job red
이중화	★진짜 회귀 게이트는 rust.yml(rust_ci 6잡)이고 이 PR 은 그 파일을 손대지 않았다 (git diff origin/main -- .github/workflows/rust.yml 빈 출력)

★효과 실증 — 「파일을 바꿨다」로 끝내지 않았다

이 브랜치 push 로 워크플로를 실제로 돌렸다:

• run 31997321117 (sha 96ea9be) · gh run watch --exit-status ★rc=0 · conclusion=success · 1m16s
• 스텝 전건 ✓ (Generate code coverage ✓ · Upload to codecov.io ✓)

⇒ ★★이 저장소 25번째 coverage run 이자 «최초의 green» 이다(앞선 24건 전부 red).

S2 특례 문구 판정

★불요해진다 — coverage 가 green 이므로 ci-presence 가 rc=1 을 내지 않고, S2~S7 게이트③ 브리프에
「coverage red 는 선재이며 머지 차단 사유 아님」을 손으로 적을 이유가 사라진다.

경계

• upstream 동기 축(S1~S7) 무접촉 — .rs/Cargo.* 변경 0
• ★coverage.yml 은 upstream 이 S2~S7 구간에서 건드리지 않는다(git log origin/main..upstream/main -- <파일> 빈 출력) ⇒ 이 수정이 뒤 회차에 충돌을 만들지 않는다
• PR [rustjava-claude-md-prune] docs: prune autonomous-sop, add self-report limits + Goal/Constraints/DoD #8 무접촉 · main 무접촉 · force-push 0 · 머지 0 · upstream 발신 0 · 시크릿 값 출력 0(이름·존재·rc 만)