gh action pypi publish
v1.12.2
このアクションにより、 dist/ディレクトリ内の Python 配布パッケージを PyPI にアップロードできるようになります。このテキストは、最小限の使用法の概要を示しています。さらに詳しいチュートリアルについては、PyPA ガイドを参照してください。
特定のアクション バージョンに関するフィードバックがある場合は、対応するリリースごとの発表ディスカッションにコメントを残してください。
masterブランチの日没masterブランチのバージョンは廃止されました。使用する GitHub Action のバージョンをmasterからrelease/v1に変更するか、正確なタグを使用するか、完全な Git コミット SHA および dependabot を使用するようにオプトインしてください。
注記
現時点では、信頼された公開を再利用可能なワークフロー内から使用することはできません。代わりに、再利用可能なワークフローを呼び出すジョブを含む再利用不可能なワークフローを作成し、その再利用不可能なワークフロー内の別のジョブから信頼できる公開ステップを実行することをお勧めします。あるいは、再利用可能なワークフロー内でユーザー名/トークンを使用することもできます。
注記
信頼された公開は、その基礎となるテクノロジーである OpenID Connect (略して OIDC) によって参照されることがあります。 PyPI のコンテキストで「OIDC パブリッシング」への参照がある場合、これが参照しているものです。
この例は、現在のベスト プラクティスに直接移行します。 API トークンを直接使用する場合、または安全性の低いユーザー名とパスワードを使用する場合は、ユーザー名とパスワードの指定方法を確認してください。
このアクションは PyPI の信頼された公開実装をサポートしており、手動で設定した API トークンやユーザー名とパスワードの組み合わせを使用せずに 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 # 重要: この権限は信頼できる公開には必須ですstep:# ここでディストリビューションを取得します- 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' &&startsWith(github.ref, 'refs/tags')
重要
デジタル証明書の生成とアップロードのサポートは現在実験段階であり、PyPI または TestPyPI を使用する信頼された発行フローにのみ限定されています。この機能のサポートはまだ安定していません。以下に説明する設定および動作は、予告なく変更される場合があります。
注記
現在、デジタル証明書の生成とアップロードには、信頼できる発行者による認証が必要です。
すべての配布ファイルに対して署名付きデジタル証明書を生成し、それらをまとめてアップロードする機能が、信頼された公開を使用するすべてのプロジェクトでデフォルトで有効になりました。これを無効にするには、次のようにattestationsを設定します。
付き: 証明書: false
構成証明オブジェクトは、配布パッケージごとに Sigstore を使用して作成され、現在のワークフローに関連付けられた GitHub の OIDC トークンによって提供される ID で署名されます。これは、信頼された発行認証と証明書の両方が同じ ID に関連付けられていることを意味します。
この GitHub アクションは、パッケージ配布の構築とは何の関係もありません。ユーザーは、このアクションを実行する前に、dist をdist/フォルダーに配置して、アップロード用に dist を準備する必要があります。
重要
この GitHub Action は Docker ベースであるため、GitHub Actions CI/CD ワークフローの GNU/Linux ベースのジョブ内からのみ使用できます。これは仕様によるものであり、多くの考慮事項を考慮しているため、変更される可能性は低いです。
ただし、これによってプラットフォーム固有の配布パッケージの公開が停止されるわけではありません。 OS 固有のホイールを構築するジョブを公開ジョブから分離することを強くお勧めします。これにより、(1) PyPI にアップロードしようとしているまったく同じアーティファクトをテストでき、(2) 並列非同期ジョブが dist の一部のみを非同期的に公開するのを防ぐことができます (ジョブの一部が失敗し、他のジョブが成功して終了した場合) (3) PyPI へのアトミック アップロードを行う (dist の一部が PyPI に表示される場合、pip などのインストーラーは依存関係の解決にそのバージョンを使用します)ただし、これにより、一部の環境ではランタイム用のホイールがまだ利用できないときに sdists を使用する可能性があります)。
この種のオーケストレーションを実装するには、 actions/upload-artifactとactions/download-artifactアクションを使用して、ステージとジョブ間で構築された dist を共有してください。次に、 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 }}リポジトリ URL: https://test.pypi.org/legacy/dist/のデフォルトのターゲット ディレクトリを任意のディレクトリに変更できます。アクションの呼び出しは次のようになります。
- 名前: パッケージを PyPI に公開する 使用: pypa/gh-action-pypi-publish@release/v1 with:packages-dir:custom-dir/
ファイルを作成した直後にtwine check実行することをお勧めしますが、アップロード前にもtwine check実行します。次の方法で麻ひものチェックを無効にすることもできます。
付き: メタデータの検証: false
複数の場所からリリースを公開すると、ワークフローが競合状態に陥ることがあります。たとえば、複数の CI から公開する場合や、同じ高レベルの行為に関するさまざまなイベントに対して GitHub Actions CI/CD 内でトリガーされる同じステップのワークフローがある場合などです。
このユースケースを容易にするために、次のようにskip-existing (デフォルトでは無効) 設定を使用できます。
付き: スキップ-既存: true
注記
プロのヒント: 可能な限り、この設定を有効にしないようにしてください。 PyPI と TestPyPI の両方にパブリッシュする手順がある場合は、後者に対してのみ使用し、前者が重複で大規模に失敗するようにすることを検討してください。
場合によっては、 twine upload失敗する場合があり、デバッグするには次のようにverbose設定を使用します。
付き: 詳細: true
PyPI 上のファイルが CI スクリプトによって自動的にアップロードされたかどうかを確認したい場合があります。アップロードするファイルの SHA256、MD5、BLAKE2-256 の値が表示されます。
with:print-hash: true
デフォルトのユーザー名の値は__token__です。 devpiなどの API トークンを提供しないカスタム レジストリに公開する場合は、カスタム ユーザー名とパスワードのペアを指定する必要がある場合があります。このようにして行われます。
with:user: guidopassword: ${{ Secrets.DEVPI_PASSWORD }} ${{ secrets.DEVPI_PASSWORD }}で使用されるシークレットは、GitHub 上のプロジェクトの設定にある環境ページで作成する必要があります。 「シークレットの作成と使用」を参照してください。
以前は、PyPI に公開する場合、自動公開のためのアクセス範囲を設定する最も安全な方法は、PyPI の API トークン機能を使用することでした。たとえば、これをプロジェクト スコープにし、環境にバインドされたシークレットとして GitHub リポジトリ設定に保存し、 ${{ secrets.PYPI_API_TOKEN }}という名前を付けます。 「シークレットの作成と使用」を参照してください。まだ安全ではありますが、サポートされているプラットフォーム (GitHub など) でのベスト プラクティスとして、API トークンを介した信頼できる公開が推奨されるようになりました。
このプロジェクトの Dockerfile と関連スクリプトおよびドキュメントは、BSD 3 条項ライセンスに基づいてリリースされています。
