Rust 캐시

Tuist는 지원되는 Rust 컴파일 결과물을 캐싱하여, 빌드 결과물이 제거된 후에도 Cargo가 이를 재사용할 수 있게 합니다. 이 캐시는 Tuist CLI에 내장되어 있습니다. 별도의 캐시 실행 파일이나 Cargo 플러그인을 설치할 필요가 없습니다.

실험용 컴파일 캐시

이 캐시는 실험 단계이며 Apple Silicon Mac에서 검증되었습니다. 라이브러리는 모든 플랫폼에서 컴파일러가 읽은 소스 기준으로 캐시되지만, Linux에서의 라이브러리 캐싱은 아직 검증되지 않았습니다. 빌드 스크립트, 프로시저럴 매크로, 실행 파일 및 네이티브 코드는 Apple Silicon Mac에서만 캐시됩니다. 캐시 키는 체크아웃 및 툴체인 경로를 플레이스홀더로 대체하므로, 동일한 머신 내의 다른 경로에 있는 체크아웃 간에는 재사용이 가능하지만 머신 간에는 재사용되지 않습니다.

캐싱 활성화#

Rust 프로젝트 설정 안내에 따라 프로젝트를 연결하고 인증하세요. 그다음 Tuist를 통해 빌드를 실행합니다:

bash

tuist cargo build --release

적합한 컴파일 작업에 대해서는 캐싱이 자동으로 수행됩니다. 추가적인 캐시 구성이나 활성화 플래그가 필요하지 않습니다. Tuist는 기존 프로젝트 및 서버 구성을 사용하여 계정의 캐시 엔드포인트를 발견하고 캐시 자격 증명을 가져옵니다.

mise를 사용하는 경우, 일반적인 cargo 명령어를 계속 입력할 수 있도록 Cargo 래퍼를 구성하세요.

작동 방식#

Cargo가 시작되기 전에, Tuist는 동일한 툴체인, 프로파일 및 구성으로 이전 빌드에서 생성된 레지스트리 및 git 의존성의 결과물을 복원하므로 Cargo는 이를 최신 상태로 인식합니다. Cargo는 무엇을 다시 빌드할지 결정하는 역할을 유지합니다. 그런 다음 Cargo가 여전히 실행하는 각 적합한 컴파일에 대해 Tuist는 다음과 같이 동작합니다:

일치하는 결과물이 있는지 로컬 캐시를 확인합니다.
로컬 캐시 미스 시, Remote Execution API(REAPI)를 통해 Kura에 쿼리하고, 누락된 콘텐츠를 다운로드한 후 복원하기 전에 결과물을 검증합니다.
캐시 미스 시, 컴파일러를 정상적으로 실행합니다. 컴파일이 성공하면 결과물을 로컬에 저장하고, 권한이 부여된 경우 REAPI를 통해 Kura에 업로드합니다. 원격 캐시 항목은 참조된 모든 콘텐츠가 사용 가능해진 후에만 게시됩니다.

로컬 빌드와 CI 빌드는 동일한 원격 캐시 프로토콜을 사용합니다. 읽기 및 쓰기 접근 권한은 Tuist 서버에서 발급한 캐시 자격 증명과 계정의 캐시 업로드 정책에서 비롯됩니다. 계정은 개발자에게 다운로드를 허용하면서도 업로드를 CI 및 계정 토큰으로 제한할 수 있습니다. 캐시 작성자는 신뢰할 수 있는 코드 생산자입니다. 캐시된 컴파일러 결과물은 실행 가능한 코드이므로, 신뢰하는 머신과 토큰에만 쓰기 접근 권한을 부여하세요.

원격 설정이 실패하더라도 로컬 캐싱은 계속 사용할 수 있습니다. 사용 불가하거나 누락되었거나 손상된 캐시 항목은 컴파일로 대체됩니다. 업로드 실패는 빌드를 실패시키거나 로컬 캐시 항목을 삭제하지 않습니다.

캐시 가능한 대상#

캐시는 다음을 지원합니다:

라이브러리 크레이트(워크스페이스 및 경로 크레이트, 의존성이 있는 크레이트, 생성된 소스가 있는 크레이트 포함). Tuist는 컴파일러가 읽은 소스를 기준으로 키를 생성합니다.
Apple silicon Mac에서는 소스 검사가 사전에 키를 생성할 수 없는 컴파일, 예를 들어 절차적 매크로, 인라인 어셈블리 또는 네이티브 라이브러리를 사용하는 크레이트, 절차적 매크로 자체, 그리고 링크된 실행 파일을 지원합니다. Tuist는 각 항목이 읽는 파일, 환경 변수 및 git describe와 같은 읽기 전용 명령어를 기록하고 이를 기준으로 키를 생성합니다.
Apple silicon Mac에서는 빌드 스크립트 실행(기본 Apple 컴파일러로 수행하는 C 컴파일 포함)을 지원합니다. 실행은 읽은 파일, 환경 및 명령어가 변경되지 않은 경우에만 복원됩니다.
경고 및 기타 진단 정보(캐시된 크레이트에서 다시 표시됨).

다음은 여전히 정상적으로 빌드됩니다:

Linux에서의 빌드 스크립트 및 기록된 컴파일.
네트워크에 연결되거나, Tuist가 관찰할 수 없는 프로그램을 시작하거나, 출력 디렉토리 외부에 기록하는 빌드 스크립트.
증분 컴파일, 사용자 정의 타겟, 그리고 지원되지 않는 컴파일러 인수 또는 소스 입력.
메타데이터 전용 cargo check 호출.
예상치 못한 컴파일러 출력을 내보내는 컴파일.

기존 전역 컴파일러 래퍼는 Tuist의 컴파일 캐시와 컴파일러 옵저버를 비활성화합니다. 사용자 정의 워크스페이스 래퍼도 캐싱을 우회합니다. 컴파일러 도구 호환성을 참조하세요.

캐시 키에는 패키지 내용, 컴파일러 및 툴체인, 인수, 빌드 환경이 포함됩니다. 체크아웃, 타겟 디렉토리, Cargo 홈 및 툴체인 위치는 플레이스홀더로 대체되므로 다른 경로의 체크아웃도 동일한 항목을 재사용합니다. env!("CARGO_MANIFEST_DIR")와 같이 자체 경로를 출력에 포함하는 크레이트는 해당 경로에서만 재사용됩니다. 자격 증명, Tuist 보고 설정, 그리고 인식된 CI 실행 메타데이터는 항목을 무효화하지 않습니다. 컴파일 중에 이러한 제외된 변수를 읽는 크레이트는 캐시되지 않습니다.

재사용 확인#

Cargo는 이미 최신 상태인 결과물의 재빌드를 피합니다. Cargo의 기존 결과물 대신 Tuist의 캐시를 테스트하려면, 한 번 빌드한 후 Cargo의 결과물을 제거하고 동일한 빌드를 다시 실행하세요:

bash

tuist cargo build --release
cargo clean
tuist cargo build --release

두 번째 빌드에서 적합한 라이브러리를 복원할 수 있으며, 지원되지 않는 크레이트는 여전히 컴파일됩니다. Cargo의 결과물을 제거해도 Tuist의 별도 로컬 캐시는 제거되지 않습니다. 이는 재사용을 확인하는 것이며, 반드시 원격 다운로드를 의미하지는 않습니다. 로컬 히트는 Kuraからの 전송이 필요하지 않습니다. 입력 검증과 캐시 작업은 오버헤드를 추가하므로, 작은 크레이트의 경우 컴파일을 피한다고 해서 빌드가 더 빨라진다는 보장은 없습니다.

캐시 활동 검사#

프로젝트 대시보드에서 Cargo Cache를 열어 히트율, 기록된 전송, 지연 시간, 처리량 및 최근 빌드를 검사하세요. 개별 작업 결정 및 CAS 출력을 확인하려면 빌드의 Cache 탭을 여세요.

누락된 측정은 0으로 계산되지 않으며, 캐시 히트가 반드시 원격 다운로드를 의미하지는 않습니다. 자세한 내용은 Rust 캐시 측정을 참조하세요.

문제 해결#

캐시 전송 및 보고 실패를 검사하려면 디버그 출력을 활성화하세요:

bash

TUIST_DEBUG=1 tuist cargo build --release

디버그 출력은 컴파일 또는 빌드 스크립트 실행이 저장되지 않은 이유도 설명합니다. 히트가 전혀 표시되지 않으면, 다른 컴파일러 래퍼가 우선권을 가지고 있지 않은지, 그리고 컴파일러, 플래그 및 환경이 캐시를 채운 빌드와 일치하는지 확인하세요. 원격 업로드의 경우 인증과 계정의 캐시 업로드 정책도 확인하세요.