Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Crater 실행 트리아지

Crater 실행하기

저희는 정기적으로 Crater 실행을 수행하며, 이 문서는 beta 실행을 트리아지하는 절차를 기술합니다. 약간의 수정을 거치면 릴리스 팀이 아닌 실행(예: PR crater 실행)에도 적용할 수 있습니다.

먼저 “Crater runs for 1.x“라는 제목의 새 이슈를 등록하십시오 (예시)

beta용 crater 실행은 beta가 나오는 즉시 시작해야 합니다. 다음 craterbot 호출을 사용하십시오.

$BETA_VERSION은 예를 들어 1.81.0-1이며, 첫 beta crater 실행이 아니라면 1을 증가시키십시오. beta rustc --version에 있는 자동 증가 카운터를 사용할 수도 있습니다.

$STABLE은 예를 들어 1.80.0(stable 릴리스)이고, $BETA는 1.81.0-beta.1입니다. https://static.rust-lang.org/manifests.txt 를 확인하여 가장 최근 channel-rust-beta.toml의 날짜를 얻은 뒤, beta-YYYY-MM-DD와 같이 날짜로 beta를 선택할 수도 있습니다.

@craterbot run name=beta-$BETA_VERSION start=$STABLE end=$BETA mode=build-and-test cap-lints=warn p=10
@craterbot run name=beta-rustdoc-$BETA_VERSION start=$STABLE end=$BETA mode=rustdoc cap-lints=warn p=5
@craterbot run name=beta-release-$BETA_VERSION start=$STABLE+cargoflags=--release end=$BETA+cargoflags=--release mode=build-and-test cap-lints=warn p=3

실행이 완료되면 이를 트리아지해야 합니다.

트리아지

이러한 단계는 일반적으로 정상적인 rustc 실행에 대해 먼저 수행한 다음, rustdoc 실행의 트리아지를 진행하고, 이어서 --release 실행의 트리아지를 진행해야 합니다. 정상적인 rustc 실행과 중복되는 rustdoc 및 --release 실행의 실패는 무시하십시오.

일반적으로 상당히 많은 리그레션이 발생합니다 – 필요한 작업량을 줄이는 데 도움이 되는 도구가 몇 가지 있습니다. 어느 것이 더 도움이 되는지는 대체로 개인 취향의 문제입니다.

  • https://github.com/Mark-Simulacrum/crater-generate-report/
    • 이것은 Cargo가 출력하는 compilation failed 메시지를 찾기 위해 로그를 파싱하여 회귀를 ’근본 원인’별로 그룹화합니다
  • https://github.com/Centril/crater-cat-errors
    • 이 도구도 마찬가지로 로그를 파싱하여 “에러” 메시지별로 리그레션을 그룹화합니다.

도구를 직접 작성하셨다면 언제든지 여기에 추가해 주십시오! 이를 위한 최선의 UI가 무엇인지는 아직 파악 중입니다.

어떤 도구를 실행했든, 결국은 수많은 로그를 읽고 그것이 진짜 실패인지 가짜 실패인지 빠르게 판단해야 합니다. 대부분의 경우 컴파일러 실패는 진짜이고 테스트 실패는 대체로 가짜이지만, 이는 보통 어느 정도 추측이 필요합니다.

어떤 것이 진짜 실패라고 판단되면, “에러 카테고리“와 함께 어딘가에(로컬 파일, HackMD, 무엇이든) 목록에 추가하십시오. 대체로 하나의 그룹 내 리그레션들이 모두 동일한 커밋 집합에 의해 발생하고, 서로 다른 그룹은 서로 다른 원인을 갖도록 항목들을 그룹화하려는 것입니다.

이 작업이 끝나서 모든 리그레션이 각각의 그룹으로 트리아지되었다면, 각 그룹마다 새 이슈를 파일링해야 합니다. 기본적으로 regression-from-stable-to-beta와 T-compiler 레이블이 있어야 하며, 표준 라이브러리 회귀인 경우에는 T-libs가 있을 수 있지만 이는 비교적 드뭅니다. 만약 실패를 일으킨 PR을 알고 있다고 생각되면, 별도의 댓글에서 해당 PR 작성자를 언급(cc)하고 PR을 링크하십시오. 그렇지 않으면 컴파일러 팀이 곧 해당 이슈를 트리아지할 것입니다.

원본 이슈에 방금 연 이슈들을 모두 링크하는 댓글을 crater 실행 결과와 함께 남기고, 가능하면 이슈 제목도 함께 적으십시오.

완료되었습니다!

크레이트에 대해 rustc를 다시 실행하기

확실하지 않은 크레이트의 경우, crater를 로컬에서 실행해 보거나 크레이트를 직접 빌드해 볼 수 있습니다 (cratesio-curl이 도움이 될 수 있습니다). 주의하십시오 – 무엇을 하든 로컬에서 임의의 코드를 실행하게 됩니다. 확신이 없는 크레이트에 대해 이슈를 등록하고 트리아지 과정이 자연스럽게 오류를 분류하도록 하는 것도 괜찮지만, 모든 크레이트에 대해 이렇게 하는 것은 좋지 않습니다. crater 실행을 몇 차례 트리아지하고 나면, 무엇이 허위 실패이고 무엇이 아닌지에 대한 상당히 좋은 감각도 얻게 됩니다.

(적어도 현재로서는) 이와 같은 방법으로 단일 크레이트에 대해서만 crater를 실행할 수 있습니다. 이 작업은 (처음 사용 시) 수 기가바이트를 다운로드하며 Docker가 실행 중이어야 함에 유의하십시오.

git clone https://github.com/rust-lang/crater
cd crater
cargo run -- prepare-local
CRATES="crates-io-crate-0.4.0,owner/repository-name" # Edit this.
cargo run -- define-ex --crate-select=list:$CRATES --cap-lints=forbid 1.38.0 beta # Edit the stable version.
cargo run -- run-graph --threads 4
cargo run -- gen-report work/ex/default/
# view report for this crate

공식 빌더에 크레이트의 일부를 다시 큐에 등록하는 것도 가능하며, 이에 대해서는 다음을 참고하십시오: https://gist.github.com/ecstatic-morse/be799bfa4d3b3d6e163fa61a9c30706f

회귀의 근본 원인 파악하기

크레이트 빌드가 왜 중단되었는지가 항상 명확한 것은 아닙니다. 이는 일반적으로 crater 트리아지의 일환으로 수행되는 작업은 아니지만, 좋은 후속 작업이 될 수 있습니다. 여기서는 cargo-bisect-rustc와 Felix의 minimization guide가 적용하기에 훌륭한 도구입니다.