此操作可讓您將dist/
目錄中的 Python 分發包上傳到 PyPI。本文提出了一個簡約的使用概述。有關更詳細的演練,請查看 PyPA 指南。
如果您對特定操作版本有任何回饋,請在相應的每次發佈公告討論中留下評論。
master
日落master
分支版本已經日落。請將您使用的 GitHub Action 版本從master
改為release/v1
或使用精確標籤,或選擇使用完整的 Git 提交 SHA 和 Dependabot。
筆記
目前無法在可重複使用工作流程中使用可信任發布。建議改為建立一個不可重複使用工作流程,其中包含呼叫可重複使用工作流程的作業,然後從該不可重複使用工作流程中的單獨作業執行可信任發布步驟。或者,您仍然可以在可重複使用工作流程中使用使用者名稱/令牌。
筆記
可信任發布有時是指其底層技術-OpenID Connect,簡稱 OIDC。如果您在 PyPI 上下文中看到對「OIDC 發布」的引用,那麼這就是他們所指的內容。
這個例子直接跳到當前的最佳實踐。如果您想直接使用 API 令牌或安全性較低的使用者名稱和密碼,請查看如何指定使用者名稱和密碼。
此操作支援 PyPI 的可信任發布實現,該實現允許對 PyPI 進行身份驗證,而無需手動配置 API 令牌或使用者名稱/密碼組合。若要使用此操作執行可信任發布,您的專案的發布者必須已在 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' &&startsWith(github.ref, 'refs/tags')
重要的
對產生和上傳數位證明的支援目前處於實驗階段,並且僅限於使用 PyPI 或 TestPyPI 的可信任發布流程。對該功能的支援尚未穩定;下面描述的設定和行為可能會更改,恕不另行通知。
筆記
目前,產生和上傳數位證明需要透過可信任發布者進行身份驗證。
對於所有使用 Trusted Publishing 的項目,現在預設啟用為所有分發文件產生簽署數位證明並將它們一起上傳的功能。要停用它,請按如下方式設定attestations
:
與:證明:假
使用 Sigstore 為每個分發包建立證明對象,並使用與目前工作流程關聯的 GitHub 的 OIDC 令牌提供的身份對它們進行簽署。這意味著可信發布身份驗證和證明都與同一身份相關聯。
此 GitHub Action 與建置包發行版無關。使用者負責在執行此操作之前將 dist 放入dist/
資料夾中來準備上傳。
重要的
由於此 GitHub Action 是基於 docker,因此只能在 GitHub Actions CI/CD 工作流程中基於 GNU/Linux 的作業中使用。這是設計使然,並且由於我們所依賴的許多考慮因素而不太可能改變。
不過,這不應阻止發布特定於平台的分發包。強烈建議將建立特定於作業系統的輪子的作業與發布作業分開。這允許(1)測試即將上傳到 PyPI 的完全相同的工件,(2)防止並行不同步作業僅異步發布部分 dist(以防部分作業失敗而其他作業成功而結束) PyPI 上的版本不完整)和(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:密碼: ${{ Secrets.TEST_PYPI_API_TOKEN }}儲存庫-url: https://test.pypi.org/legacy/
您可以將dist/
的預設目標目錄變更為您喜歡的任何目錄。操作調用現在如下所示:
- 名稱:將套件發佈到 PyPI 使用:pypa/gh-action-pypi-publish@release/v1 與:包目錄:自訂目錄/
建議您在產生檔案後立即執行twine check
,但這也會在上傳之前執行twine check
。您也可以透過以下方式停用麻繩檢查:
與:驗證元資料:假
有時,當您從多個位置發布版本時,您的工作流程可能會遇到競爭條件。例如,從多個 CI 發佈時,甚至在 GitHub Actions CI/CD 中針對涉及相同高階行為的不同事件觸發具有相同步驟的工作流程時。
為了方便此用例,您可以使用skip-existing
(預設為停用)設置,如下所示:
與:跳過現有:true
筆記
專業提示:盡可能避免啟用此設定。如果您有發佈到 PyPI 和 TestPyPI 的步驟,請考慮僅將其用於後者,而前者在重複時會嚴重失敗。
有時, twine upload
可能會失敗,並且要使用verbose
設定進行偵錯,如下所示:
與:詳細:真實
您可能想要驗證 PyPI 上的檔案是否是由 CI 腳本自動上傳的。它將顯示要上傳的檔案的 SHA256、MD5、BLAKE2-256 值。
與:列印哈希:true
預設使用者名稱值為__token__
。如果您發佈到不提供 API 令牌的自訂註冊表(例如devpi
),您可能需要指定自訂使用者名稱和密碼對。就是這樣完成的。
與:使用者:guido密碼:${{secrets.DEVPI_PASSWORD}}
${{ secrets.DEVPI_PASSWORD }}
中使用的金鑰需要在 GitHub 上專案設定下的環境頁面上建立。請參閱建立和使用機密。
過去,在發佈到 PyPI 時,自動發佈的存取範圍最安全的方式是使用 PyPI 的 API 令牌功能。例如,可以將其設定為專案範圍並在 GitHub 儲存庫設定中儲存為環境綁定的機密,將其命名為${{ secrets.PYPI_API_TOKEN }}
。請參閱建立和使用機密。雖然仍然安全,但現在鼓勵透過 API 令牌進行可信任發布,作為受支援平台(如 GitHub)上的最佳實踐。
本專案中的 Dockerfile 以及相關腳本和文件是根據 BSD 3 條款授權發布的。