Skip to content

ci: verify cargo-binstall and key caches by the tools that fill them - #980

Open
owjs3901 wants to merge 1 commit into
mainfrom
ci/toolchain-cache-keys
Open

owjs3901 wants to merge 1 commit into
mainfrom
ci/toolchain-cache-keys

Conversation

@owjs3901

@owjs3901 owjs3901 commented Nov 15, 2026 •

Copy link
Copy Markdown
Contributor

Summary

감사 이슈 #683 의 INF-19 (CI 툴체인이 가변적) 와 INF-20 (캐시 키에 툴체인 차원이 없음) 중, 프로젝트의 CI 정책과 양립하는 부분을 구현합니다.

프로젝트 정책: CI 는 ubuntu-latest, 최신 stable Rust, 최신 Bun/Node/wasm-pack/cargo-binstall 등을 쓰고, 예외는 tarpaulin 커버리지 실행의 Rust 1.99.1 고정 하나뿐이다 (tarpaulin 이 1.100 을 읽을 수 있을 때까지). 이 PR 은 이 고정을 바꾸지 않습니다.

INF-19

  • 구현: install-wasm-pack 앵커 스텝 (8개 잡이 공유)에서 raw.githubusercontent.com/cargo-bins/cargo-binstall/main/install-from-binstall-release.sh | bash 를 없앴습니다. 대신 gh api .../releases/latest 로 최신 릴리스의 cargo-binstall-x86_64-unknown-linux-musl.tgz 를 받아 GitHub 가 기록한 에셋 sha256 digest 로 sha256sum -c 검증한 뒤 ~/.cargo/bin 에 풉니다. (Bun 을 받는 native-consumer 잡과 같은 방식입니다.) 이제 main 브랜치의 셸 스크립트를 그대로 실행하지 않고, 체크섬을 확인한 릴리스 바이너리만 실행합니다. 이 러너 (Linux-X64) 가 아니면 바로 실패합니다.
  • 이미 main 에 반영됨: 감사가 지적한 jetli/wasm-pack-action@v0.4.0 은 이미 사용하지 않습니다 (cargo-binstall 로 최신 stable wasm-pack 을 설치하고 crates.io 최신 버전과 일치하는지 검증).
  • 정책과 충돌해 구현하지 않음: 러너 (ubuntu-latest), 툴 버전 (latest/stable), cargo-binstall 을 고정된 릴리스로 핀하라는 부분은 "CI 는 항상 최신 릴리스를 쓴다"는 정책과 정면으로 충돌합니다. 그래서 버전은 계속 최신을 따르되, 가변성의 위험 (무엇이 실행됐는지 모름, 검증 없는 원격 스크립트) 은 체크섬 검증과 아래 INF-20 의 캐시 키로 줄였습니다. 액션 SHA 고정은 별도 PR ci: pin every GitHub Action to a full commit SHA #979 (INF-18) 에서 다룹니다.

INF-20

cargo / Bun / Playwright 캐시 키 (8개 잡, 21개 키)에 내용물이 실제로 의존하는 차원을 넣었습니다.

  • 러너 이미지: 새 앵커 스텝 record-runner-image 가 ImageOS (예: ubuntu24) 를 RUNNER_IMAGE 로 기록하고 모든 키에 넣습니다. ubuntu-latest 가 새 Ubuntu 릴리스로 넘어가면 캐시가 갈립니다. 매주 바뀌는 ImageVersion 은 넣지 않았습니다. 그걸 넣으면 내용물이 그대로인데도 캐시가 매주 무효화되기 때문입니다.
  • Rust: setup-rust-toolchain 에 id: rust 를 주고 cargo 키에 steps.rust.outputs.cachekey (rustc 커밋 날짜+해시) 를 넣었습니다.
  • Bun: setup-bun 에 id: bun 을 주고 Bun 키에 steps.bun.outputs.bun-version 을 넣었습니다.
  • Playwright: 새 앵커 스텝 record-playwright-revisions 가 bunx playwright install --dry-run 의 설치 위치에서 브라우저 빌드 (예: chromium-1243_chromium_headless_shell-1243_firefox-1543_...) 를 읽어 키에 넣습니다. 그래서 키가 bun.lock 전체 해시 대신 실제 브라우저 리비전을 따라갑니다. Playwright 와 무관한 의존성 변경으로 캐시가 무효화되지 않습니다.
  • 넣지 않은 차원: Node.js 와 wasm-pack 은 캐시되는 어떤 경로에도 내용물을 만들지 않아 (Bun 캐시는 Bun 이, target/ 은 rustc 가 채움) 키에 넣지 않았습니다. publish 잡의 커버리지 툴체인 1.99.1 은 워크플로 안의 상수라 키에 따로 넣지 않았습니다. cargo 는 rustc 가 바뀌면 fingerprint 로 다시 빌드합니다.

다른 PR 과의 겹침

Test plan

  • actionlint 1.7.12: 새 오류 없음 (기존에도 있던 windows-11-vs2026-arm 러너 라벨 경고만 출력). YAML 앵커/별칭도 정상 파싱
  • cargo-binstall-x86_64-unknown-linux-musl.tgz (v1.27.0) 를 받아 sha256sum 이 API 의 digest 와 같은지, tarball 루트에 cargo-binstall 하나만 있는지 확인
  • Playwright 리비전 추출 파이프라인 (sed | sort | paste) 을 --dry-run 출력 형식으로 확인
  • git diff --stat: publish.yml 한 파일, 줄 끝 형식 유지
  • 이 PR 의 CI 에서 wasm-pack 설치 스텝과 각 잡의 캐시 저장/복원 키 확인

Refs #683

🤖 Generated with Claude Code

cargo-binstall is now the latest release binary, checked against the SHA-256
digest GitHub records for the asset, instead of the installer script piped
from the repository's main branch.

Every cargo, Bun and Playwright cache key now also names what its contents
depend on: the hosted image's OS release (ImageOS), the rustc build reported
by setup-rust-toolchain, the Bun version setup-bun installed, and the browser
builds the installed Playwright downloads. Cargo and Bun keys keep their
lockfile hash; the Playwright key uses the browser builds in place of the
bun.lock hash.

CI keeps running the latest runner, tools and stable Rust, and the coverage
run keeps Rust 1.99.1.

Refs #683 (INF-19, INF-20)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@codecov

codecov Bot commented Nov 15, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant