gh action pypi publish
v1.12.2
이 작업을 통해 dist/ 디렉터리에 있는 Python 배포 패키지를 PyPI에 업로드할 수 있습니다. 이 텍스트는 최소한의 사용법 개요를 제안합니다. 더 자세한 연습을 보려면 PyPA 가이드를 확인하세요.
특정 액션 버전에 대한 피드백이 있는 경우 해당 릴리스별 공지 토론에 의견을 남겨주세요.
master 브랜치 일몰 master 브랜치 버전이 종료되었습니다. 사용하는 GitHub Action 버전을 master 에서 release/v1 로 변경하거나 정확한 태그를 사용하거나 전체 Git 커밋 SHA 및 종속 로봇을 사용하도록 선택하세요.
메모
현재는 재사용 가능한 워크플로 내에서 신뢰할 수 있는 게시를 사용할 수 없습니다. 대신 재사용 가능 워크플로를 호출하는 작업이 포함된 재사용 불가능 워크플로를 만든 다음 해당 재사용 가능 워크플로 내의 별도 작업에서 신뢰할 수 있는 게시 단계를 수행하는 것이 좋습니다. 또는 재사용 가능한 워크플로 내에서 사용자 이름/토큰을 계속 사용할 수 있습니다.
메모
신뢰할 수 있는 게시는 기본 기술인 OpenID Connect, 줄여서 OIDC라고도 합니다. PyPI의 맥락에서 "OIDC 게시"에 대한 참조가 표시되면 이것이 그들이 참조하는 것입니다.
이 예는 현재 모범 사례로 바로 이동합니다. API 토큰을 직접 사용하거나 덜 안전한 사용자 이름과 비밀번호를 사용하려면 사용자 이름과 비밀번호를 지정하는 방법을 확인하세요.
이 작업은 수동으로 구성된 API 토큰이나 사용자 이름/비밀번호 조합 없이 PyPI에 대한 인증을 허용하는 PyPI의 신뢰할 수 있는 게시 구현을 지원합니다. 이 작업으로 신뢰할 수 있는 게시를 수행하려면 프로젝트 게시자가 PyPI에 이미 구성되어 있어야 합니다.
신뢰할 수 있는 게시 흐름을 시작하려면 명시적인 사용자 이름이나 비밀번호 없이 id-token: write 권한을 사용하여 이 작업의 작업을 구성하세요.
# .github/workflows/ci-cd.ymljobs: pypi-publish:name: PyPIruns-on에 릴리스 업로드: ubuntu-latestenvironment: name: pypi url: https://pypi.org/p/<your-pypi-project -name>permissions: id-token: write # 중요: 이 권한은 신뢰할 수 있는 게시 단계에 필수입니다.# 여기에서 배포판을 검색하세요.- name: 패키지 게시 PyPI에 대한 배포는 다음을 사용합니다: pypa/gh-action-pypi-publish@release/v1
메모
전문가 팁: unstable/v1 과 같은 분기 포인터를 사용하는 대신 태그가 지정된 버전이나 sha1 커밋 식별자에 사용하는 작업 버전을 고정하세요. 이렇게 하면 워크플로가 더욱 안전해지고 재현성이 향상되어 갑작스럽고 불쾌한 상황을 피할 수 있습니다.
TestPyPI와 같이 신뢰할 수 있는 게시를 지원하는 다른 인덱스도 사용할 수 있습니다.
- 이름: TestPyPI에 패키지 배포판 게시 용도: pypa/gh-action-pypi-publish@release/v1 with:repository-url: https://test.pypi.org/legacy/
(환경 이름을 testpypi 또는 이와 유사한 것으로 업데이트하는 것을 잊지 마세요!)
메모
전문가 팁: 전역이 아닌 게시를 수행하는 작업에서만 id-token: write 권한을 설정하세요. 또한 빌드와 게시를 분리해 보십시오. 이렇게 하면 빌드 또는 테스트 환경에 악의적으로 삽입된 스크립트가 감시망을 피해 날아가는 동안 권한을 상승시킬 수 없게 됩니다.
일반적인 사용 사례는 태그가 지정된 커밋에서만 패키지를 업로드하는 것입니다. 이를 위해 작업에 필터를 추가합니다.
if: github.event_name == 'push' && startWith(github.ref, 'refs/tags')
중요한
디지털 증명 생성 및 업로드에 대한 지원은 현재 실험적이며 PyPI 또는 TestPyPI를 사용하는 신뢰할 수 있는 게시 흐름으로만 제한됩니다. 이 기능에 대한 지원은 아직 안정적이지 않습니다. 아래 설명된 설정 및 동작은 사전 통지 없이 변경될 수 있습니다.
메모
현재 디지털 증명을 생성하고 업로드하려면 신뢰할 수 있는 게시자의 인증이 필요합니다.
모든 배포 파일에 대해 서명된 디지털 증명을 생성하고 모두 함께 업로드하는 기능은 이제 Trusted Publishing을 사용하는 모든 프로젝트에 대해 기본적으로 설정되어 있습니다. 이를 비활성화하려면 다음과 같이 attestations 설정하십시오.
포함: 증명: false
증명 개체는 각 배포 패키지에 대해 Sigstore를 사용하여 생성되며, 현재 워크플로와 연결된 GitHub의 OIDC 토큰에서 제공하는 ID로 서명합니다. 이는 신뢰할 수 있는 게시 인증과 증명이 모두 동일한 ID에 연결되어 있음을 의미합니다.
이 GitHub 작업은 패키지 배포판 작성 과 관련이 없습니다. 사용자는 이 작업을 실행하기 전에 업로드할 dist를 dist/ 폴더에 넣어 준비할 책임이 있습니다.
중요한
이 GitHub Action은 Docker 기반이므로 GitHub Actions CI/CD 워크플로의 GNU/Linux 기반 작업 내에서만 사용할 수 있습니다. 이는 의도적으로 설계된 것이며 우리가 의존하는 여러 가지 고려 사항으로 인해 변경될 가능성이 없습니다.
하지만 이것이 플랫폼별 배포 패키지 게시를 중단해서는 안 됩니다. 게시 작업에서 OS별 휠을 구축하기 위한 작업을 분리하는 것이 좋습니다. 이를 통해 (1) PyPI에 업로드될 정확히 동일한 아티팩트를 테스트하고, (2) 병렬 비동기 작업이 dist의 일부만 비동기적으로 게시하는 것을 방지할 수 있습니다(작업의 일부가 실패하고 다른 작업이 성공하는 경우). PyPI의 불완전한 릴리스) 및 (3) PyPI에 원자적 업로드를 수행합니다(PyPI에 dist의 일부가 나타나면 pip와 같은 설치 프로그램은 종속성 해결을 위해 해당 버전을 사용하지만 이로 인해 일부 환경에서 런타임용 휠을 아직 사용할 수 없는 동안 sdists를 사용하십시오.
이러한 종류의 오케스트레이션을 구현하려면 여러 단계와 작업에서 빌드된 dist를 공유하기 위해 actions/upload-artifact 및 actions/download-artifact 작업을 사용하십시오. 그런 다음 needs 설정을 사용하여 빌드, 테스트 및 게시 단계의 순서를 지정합니다.
최상의 결과를 얻으려면 프로젝트의 특정 요구 사항에 맞는 워크플로우 종류를 파악하십시오.
예를 들어, 모든 커밋을 TestPyPI 또는 devpi 와 같은 자체 인덱스 서버로 푸시하는 병렬 작업을 구현할 수 있습니다. 이를 위해서는 (1) 사용자 정의 repository-url 값을 지정하고 (2) 충돌이 발생하지 않도록 각 업로드에 대해 고유한 버전 번호를 생성해야 합니다. 후자는 setuptools_scm 패키지를 사용하는 경우 가능하지만 최신 태그 커밋까지의 거리를 기반으로 자신만의 솔루션을 만들 수도 있습니다.
별도의 호스트에 대해 또 다른 토큰을 생성한 다음 작업에 사용되는 환경에서 GitHub 저장소 비밀로 저장해야 합니다. 그러나 비밀번호를 전달하면 비밀 없는 신뢰할 수 있는 게시가 비활성화되므로 대신 TestPyPI에 게시할 때 사용자 정의가 아닌 구성하는 것이 좋습니다.
이 경우 작업 호출은 다음과 같습니다.
- 이름: TestPyPI에 패키지 게시
용도: pypa/gh-action-pypi-publish@release/v1
with:password: ${{ secrets.TEST_PYPI_API_TOKEN }}repository-url: https://test.pypi.org/legacy/ dist/ 의 기본 대상 디렉터리를 원하는 디렉터리로 변경할 수 있습니다. 이제 작업 호출은 다음과 같습니다.
- 이름: PyPI에 패키지 게시 용도: pypa/gh-action-pypi-publish@release/v1 with:패키지-dir: 사용자 정의-dir/
파일을 생성한 직후에 twine check 실행하는 것이 좋지만 업로드하기 전에 twine check 도 실행됩니다. 다음을 사용하여 꼬기 검사를 비활성화할 수도 있습니다.
포함: 메타데이터 확인: false
경우에 따라 여러 위치에서 릴리스를 게시할 때 워크플로가 경쟁 조건에 부딪힐 수 있습니다. 예를 들어 여러 CI에서 게시하거나 동일한 상위 수준 작업과 관련된 다양한 이벤트에 대해 GitHub Actions CI/CD 내에서 동일한 단계의 워크플로가 트리거되는 경우가 있습니다.
이 사용 사례를 용이하게 하기 위해 다음과 같이 skip-existing (기본적으로 비활성화됨) 설정을 사용할 수 있습니다.
포함: 기존 건너뛰기: true
메모
전문가 팁: 가능하면 이 설정을 활성화하지 마세요. PyPI와 TestPyPI 모두에 게시하는 단계가 있는 경우 후자에만 사용하는 것을 고려하세요. 전자는 중복 시 크게 실패합니다.
때로는 twine upload 실패할 수 있으며 디버그하려면 다음과 같이 verbose 설정을 사용하십시오.
포함: 자세한 내용: 사실
PyPI의 파일이 CI 스크립트에 의해 자동으로 업로드되었는지 확인하고 싶을 수 있습니다. 업로드할 파일의 SHA256, MD5, BLAKE2-256 값이 표시됩니다.
with:print-hash: 참
기본 사용자 이름 값은 __token__ 입니다. devpi 와 같이 API 토큰을 제공하지 않는 사용자 정의 레지스트리에 게시하는 경우 사용자 정의 사용자 이름 및 비밀번호 쌍을 지정해야 할 수도 있습니다. 이것이 완료된 방법입니다.
with:사용자: guidopassword: ${{ secrets.DEVPI_PASSWORD }} ${{ secrets.DEVPI_PASSWORD }} 에 사용되는 비밀은 GitHub의 프로젝트 설정에 있는 환경 페이지에서 생성되어야 합니다. 비밀 만들기 및 사용을 참조하세요.
과거에는 PyPI에 게시할 때 자동 게시를 위한 액세스 범위의 가장 안전한 방법은 PyPI의 API 토큰 기능을 사용하는 것이었습니다. 예를 들어 이를 프로젝트 범위로 만들고 GitHub 저장소 설정에 환경 바인딩된 비밀로 저장하여 이름을 ${{ secrets.PYPI_API_TOKEN }} 으로 지정합니다. 비밀 만들기 및 사용을 참조하세요. 여전히 안전하면서도 신뢰할 수 있는 게시는 이제 GitHub와 같은 지원 플랫폼에서 모범 사례로 API 토큰을 통해 권장됩니다.
이 프로젝트의 Dockerfile과 관련 스크립트 및 문서는 BSD 3 조항 라이선스에 따라 릴리스됩니다.
