밀폐

문제 신고 소스 보기 1박 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

이 페이지에서는 밀폐성, 밀폐 빌드 사용의 이점 및 빌드에서 밀폐되지 않은 동작을 식별하기 위한 전략입니다.

개요

동일한 입력 소스 코드와 제품 구성이 제공되면 밀폐 빌드 시스템이 변경사항으로부터 빌드를 분리하여 항상 동일한 출력을 반환함 호스트 시스템에 보냅니다.

빌드를 격리하기 위해 밀폐 빌드는 라이브러리와 로컬 또는 원격 호스트 머신에 설치된 다른 소프트웨어입니다. 그들은 빌드 도구의 특정 버전(예: 컴파일러, 종속 항목) 제공합니다 이렇게 하면 빌드 프로세스가 독립 실행 상태로 외부 호스팅 서비스를 제공할 수 있습니다

밀폐성의 두 가지 중요한 측면은 다음과 같습니다.

격리: 밀폐 빌드 시스템은 도구를 소스 코드로 취급합니다. 그들은 도구 사본을 다운로드하고 저장용량 및 관리되는 파일 내 사용을 관리합니다. 수 있습니다. 이렇게 하면 호스트 머신과 로컬 사용자가 격리됩니다. 여기에는 설치된 언어 버전도 포함됩니다.
소스 ID: 밀폐 빌드 시스템은 인코더-디코더입니다 Git과 같은 코드 리포지토리는 고유한 해시 코드가 필요합니다. 밀폐 빌드 시스템은 이 해시를 사용하여 빌드의 입력을 생성합니다

밀폐 빌드의 주요 이점은 다음과 같습니다.

속도: 작업의 출력을 캐시할 수 있으며 작업을 캐시할 필요가 없습니다. 다시 실행됩니다
병렬 실행: 주어진 입력과 출력에 대해 빌드 시스템에서 다음을 수행할 수 있습니다. 모든 행동의 그래프를 작성하여 효율 및 병렬 계산 실행할 수 있습니다 빌드 시스템이 규칙을 로드하고 작업 그래프를 계산합니다. 캐시에서 찾을 수 있도록 입력을 해시합니다.
여러 빌드: 한 빌드에 여러 개의 밀폐 빌드를 만들 수 있습니다. 각 빌드마다 다른 도구와 버전을 사용하여 빌드됩니다.
재현성: 밀폐 빌드는 문제 해결에 좋습니다. 왜냐하면 빌드를 생성한 정확한 조건을 알 수 있습니다.

Bazel로 전환할 준비를 하고 있는 경우 기존 빌드를 사전에 밀폐성을 고려합니다. 의 일반적인 원인 빌드의 비밀폐성은 다음과 같습니다.

.mk 파일에서 임의 처리
비결정적으로 파일을 생성하는 작업 또는 도구(일반적으로 수반되는 작업) 빌드 ID 또는 타임스탬프
호스트 간에 다른 시스템 바이너리 (예: /usr/bin 바이너리, 절대 경로, 네이티브 C++ 규칙 자동 구성을 위한 시스템 C++ 컴파일러)
빌드 중에 소스 트리에 쓰기 이렇게 하면 동일한 소스가 다른 대상에 사용되지 않도록 할 수 있습니다. 첫 번째 빌드는 소스에 대상 A의 소스 트리를 수정합니다. 그런 다음 타겟 B를 빌드하려고 하면 있습니다

로컬 실행부터 로컬 캐시 적중에 영향을 미치는 문제가 나타납니다. 작업을 수행할 수 있습니다.

null 순차 빌드 보장: make를 실행하고 빌드에 성공하면 다시 빌드해도 대상이 다시 빌드되면 안 됩니다. 각 빌드를 실행하면 다른 시스템에서 파일 콘텐츠의 해시를 비교하고 결과가 다르면 빌드를 재현할 수 없습니다.
단계 실행 로컬 캐시 적중 디버그 잠재적 클라이언트 시스템의 다양한 코드를 수집하여 클라이언트 환경이 작업에 유출되는 경우
단지 컨테이너 이미지만 포함된 Docker 컨테이너 내에서 빌드를 실행합니다. 확인된 소스 트리와 명시적인 호스트 도구 목록이 포함되어 있습니다. 단절과 고장 오류 메시지가 암시적 시스템 종속 항목을 포착합니다.
다음을 사용하여 밀폐성 문제를 발견하고 수정합니다. 원격 실행 규칙을 참조하세요.
엄격한 샌드박스 사용 설정 빌드의 작업은 스테이트풀(Stateful)이고 영향을 주지 않습니다
Workspace 규칙 개발자가 외부 작업공간에 종속 항목을 추가할 수 있지만 프로세스에서 임의의 처리를 수행할 수 있을 만큼 충분히 풍부합니다. 다음을 수행할 수 있습니다. Bazel 작업공간 규칙에서 밀폐되지 않을 수 있는 일부 작업의 로그를 플래그 추가 --experimental_workspace_rules_log_file=PATH부터 Bazel 명령어를 사용하세요

다른 프로젝트의 밀폐 사용 성공 사례를 자세히 알아보려면 자세한 내용은 다음 BazelCon 대담을 참조하세요.