Crater 실행 트리아지
Crater 실행하기
우리는 정기적으로 Crater를 실행하며, 이 문서는 beta 실행을 트리아지하는 절차를 설명합니다. 약간만 수정하면 릴리스 팀이 아닌 곳에서 수행하는 실행(예: PR Crater 실행)에도 적용할 수 있습니다.
먼저 “1.x에 대한 Crater 실행“이라는 제목으로 새 이슈를 등록하십시오(예시).
beta가 나오는 즉시 beta에 대한 Crater 실행을 시작해야 합니다. 다음 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 실행을 트리아지합니다. rustdoc 실행과 --release 실행에서 발생한 실패 중 일반 rustc 실행과 중복되는 것은 무시하십시오.
보통 회귀가 꽤 많이 발생합니다. 해야 할 작업량을 줄이는 데 도움이 되는 도구가 몇 가지 있습니다. 어느 도구가 더 유용한지는 대체로 개인 취향의 문제입니다.
- https://github.com/Mark-Simulacrum/crater-generate-report/
- 이 도구는 로그를 파싱하여 Cargo가 출력한 컴파일 실패 메시지를 찾아 회귀를 ’근본 원인’별로 그룹화합니다.
- https://github.com/Centril/crater-cat-errors
- 이 도구도 로그를 파싱하여 회귀를 “error” 메시지별로 그룹화합니다.
직접 작성한 도구가 있다면 자유롭게 여기에 추가하십시오! 이를 위한 최선의 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의 최소화 가이드는 활용하기에 훌륭한 도구입니다.