네트워크 밖에서 Python wheel을 빌드하고 안에서 배포하기

이미 wheel을 만드는 빌드 작업과 그것을 받아야 할 프라이빗 리포지토리가 있습니다. 실수는 두 번째 작업이 브랜치에서 다시 빌드하게 하고 그 결과를 같은 릴리스라고 부르는 것입니다. 테스트한 파일을 그대로 옮기고, 다이제스트로 이름을 붙이며, 업로드 자격 증명은 안쪽에 두십시오. 아래 설명은 공개 CI 러너에서 내부 배포자까지 하나의 산출물을 따라갑니다.

소스가 이미 있는 곳에서 빌드하기

소스와 도구 체인, 테스트 모음이 이미 갖춰진 작업에서 빌드를 실행합니다. 프라이빗 리포지토리 때문에 그 작업이 저장소에 닿아야 할 이유는 없습니다. 프로젝트가 이미 쓰는 환경에 빌드 프런트엔드를 설치하고, 프로젝트가 두 배포 형식을 모두 제공한다면 둘 다 생성합니다.

python -m build --sdist --wheel --outdir dist
python -m twine check dist/*

출력 디렉터리는 작고 일회용으로 유지합니다. 다음 작업이 배포할 파일과 그 해시만 넘기면 충분합니다. 가상 환경과 캐시를 포함한 나머지는 기록된 소스 리비전에서 다시 만들 수 있습니다. 군더더기 없는 산출물은 검토도 쉽습니다. 안의 모든 파일이 누군가 들여다볼 수 있는 파일이기 때문입니다.

무엇이 만들었는지 기록합니다. 파일 이름에서 읽은 패키지 이름과 버전, 소스 리비전, 그리고 그것을 만든 워크플로 실행입니다. 버전 문자열만으로는 파일을 식별할 수 없습니다. 같은 버전이라도 서로 다른 커밋에서 두 번 빌드될 수 있기 때문입니다. 산출물 설명에 파일 이름 옆에 리비전을 적고, 그 기록을 인계의 일부로 다루십시오.

다시 빌드하라는 지시가 아니라 바이트를 옮기기

두 번째 빌드는 두 번째 제품입니다. 타임스탬프, 함께 묶인 의존성, 도구 버전이 모두 바이트를 바꿀 수 있으므로 다시 빌드에는 자체 테스트 증거와 자체 검토가 필요합니다. 대신 이미 검토한 파일을 승격하십시오.

배포 파일을 CI 플랫폼이 제공하는 산출물 저장소에 업로드하고, 내부 작업에는 브랜치 이름이 아니라 그 특정 산출물에 대한 참조를 넘깁니다.

sha256sum dist/*.whl dist/*.tar.gz
# keep the digests beside the run id in the artifact description

플랫폼이 서명된 출처를 지원한다면 산출물을 증명하도록 요청하고, 나중에 기대하는 리포지토리와 워크플로, 소스 리비전을 검증합니다. GitHub의 증명 문서가 그런 형태의 주장을 설명합니다. 유효한 서명은 출처의 증거이며, 취약점 스캔도 아니고 권한 부여 결정도 아닙니다.

업로드 전에 안쪽에서 검증하기

내부 작업은 받은 파일이 승인된 파일인지 확인하는 것부터 시작합니다. 다이제스트는 빌드 작업의 기록과 비교하고, 도착한 것에서 다시 계산한 값과 비교하지 않습니다.

sha256sum -c digests.txt
python -m twine check dist/*

다음으로 메타데이터를 읽습니다. 패키지 이름과 버전, 선언된 의존성이 승인한 검토와 맞아야 합니다. 이름은 맞아 보이지만 의존성 고정이 바뀐 wheel은 같은 라벨을 단 다른 패키지입니다. 메타데이터가 움직였다면 그 산출물을 미승인으로 보고 어느 빌드가 만들었는지 밝혀내십시오.

다이제스트가 맞지 않으면 멈춥니다. 업로드하지 말고, 그 자리에서 다시 빌드해 고치지도 마십시오. 전송 중에 무언가 바뀌었다는 증거가 지워지기 때문입니다. 불일치는 산출물 저장소, 내려받기 단계, 기록 중 하나가 틀렸다는 뜻이며, 릴리스가 배포되기 전에 각각 설명이 필요합니다.

중복 버전 응답 다루기

프라이빗 리포지토리는 보통 기존 버전 덮어쓰기를 거부하며, 그 거부는 기능입니다. 버전이 있어 업로드가 실패하면 그 버전에 대한 리포지토리 기록을 살피고, 보관 중인 파일을 배포하려던 다이제스트와 비교합니다.

기존 버전은 이전 업로드가 성공했는데 응답이 유실되었다는 뜻일 수도 있고, 누군가 같은 번호로 다른 내용을 배포했다는 뜻일 수도 있습니다.

버전을 지우지 말고, 오류를 피하려고 새 번호를 지어내지도 마십시오. 저장된 내용이 받아들일 만한지 릴리스 책임자와 결정한 뒤 결과를 기록합니다. 내용이 다르다면 그것은 버전 관리 문제이지 파이프라인 문제가 아닙니다.

업로드 자격 증명을 한쪽에 두기

리포지토리 자격 증명이 필요한 것은 내부 배포자뿐이며, 업로드가 진행되는 동안만 필요합니다. 토큰은 대상 리포지토리와 업로드 작업으로 범위를 좁히고, 내부 시스템의 시크릿 저장소에 두며, 빌드 작업에서는 완전히 빼십시오. 빌드 작업이 배포할 수 있다면 빌드를 바꿀 수 있는 누구나 배포할 수 있습니다.

어떤 내부 워크플로가 배포자를 시작할 수 있는지도 제한합니다. 승인을 필수로 둔 수동 트리거는 릴리스에 합당한 기본값입니다. 아무 브랜치에나 푸시하는 것은 아닙니다.

완료된 릴리스는 세 가지를 남겨야 합니다. 배포 파일, 소스 리비전과 함께 있는 그 다이제스트, 그리고 같은 버전을 보여 주는 리포지토리 기록입니다.