V8 버전 업데이트

V8 버전 업데이트은(는) 무엇을 하나요?

핵심 워크플로우

1. third_party/v8/README.md를 읽고 해당 문서에 명시된 버전 범프 시퀀스를 따릅니다. 이 문서를 릴리스 프로세스의 근본 원천(source of truth)으로 취급합니다.

2. 핀(pin)을 가지고 있는 구체적인 저장소 표면을 검사하고 업데이트합니다:

   • codex-rs/Cargo.toml
   • codex-rs/Cargo.lock
   • MODULE.bazel
   • third_party/v8/BUILD.bazel
   • third_party/v8/README.md
   • 나머지 사전 빌드된 입력이 변경될 때 일치하는 third_party/v8/rusty_v8_<version>.sha256 매니페스트

3. 기존 checksum 헬퍼를 루프에 포함시킵니다:

   python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
   python3 .github/scripts/rusty_v8_bazel.py check-module-bazel
   python3 -m unittest discover -s .github/scripts -p test_rusty_v8_bazel.py
   

4. 작업 범위를 넓히기 전에 릴리스 후보 경로를 검증합니다:

   • 가능한 경우, 해당 후보 브랜치나 PR에 대한 v8-canary CI 결과를 GitHub 검사 도구 또는 gh를 사용하여 확인하는 것을 선호합니다.
   • CI를 사용할 수 없거나 사용자가 로컬 전용 확인을 요청한 경우, 변경된 표면에 대해 실용적인 가장 가까운 로컬 검증을 실행하고 이것이 전체 호스팅 카나리를 대체하는 로컬 대체 검증임을 명시적으로 밝힙니다.

5. 카나리 경로가 통과하면 거기서 멈춥니다. 결과를 요약하고 사용자에게 후보 변경 사항을 커밋하거나 요청한 릴리스 흐름을 진행하도록 권장합니다. 사용자가 요청하지 않는 한 태그, 릴리스, 푸시를 게시하지 마십시오.

실패 경로

이 경로는 카나리 또는 로컬 빌드 경로가 실패할 때만 진입합니다.

1. 실패한 대상(target), 워크플로우 작업, 및 첫 번째 실행 가능한 오류를 캡처합니다.
2. 현재 고정된 버전을 관련 상류(upstream) 태그 또는 SHA의 대상 버전과 비교합니다. 다음 두 가지를 모두 검사합니다:
   • denoland/rusty_v8
   • 대상 Bazel 고정 버전의 상류 V8 소스
3. 광범위한 소스 변경 사항보다는 빌드 관련 델타(delta)를 추적합니다:
   • 생성된 바인딩 레이아웃 변경
   • 아카이브 또는 자산 명명 변경
   • GN/Bazel 타겟 변경
   • 사용자 정의 libc++ / libc++abi / llvm-libc 입력
   • 샌드박스 또는 포인터 압축 기능 관계
   • patches/ 디렉토리의 패치 중 더 이상 적용되지 않거나 상류와 일치하지 않는 부분
4. 각 실패하는 델타를 Codex의 빌드 그래프로 추적합니다:
   • MODULE.bazel
   • third_party/v8/BUILD.bazel
   • .github/scripts/rusty_v8_bazel.py
   • .github/workflows/v8-canary.yml
   • .github/workflows/rusty-v8-release.yml
5. 대상 버전의 빌드 및 아티팩트 계약을 복원하는 데 필요한 부분만 업데이트합니다. 패치 설명과 문서 변경 사항은 영향을 받는 파일 가까이에 유지합니다.
6. 집중 검증을 다시 실행합니다. 통과하면 일반 워크플로우로 돌아가고 간결한 요약과 남은 릴리스 단계와 함께 중단합니다.

보고

• 검증이 호스팅된 v8-canary에서 왔는지 로컬 대체 검증에서 왔는지 말합니다.
• "버전 범프 완료"와 "릴리스 게시됨"을 구분합니다.
• 차단된 경우, 중요 상류 델타, 영향을 받는 Codex 파일, 그리고 시도할 다음 구체적인 수정 사항을 보고합니다.