gh action pypi publish
v1.12.2
Это действие позволяет вам загрузить дистрибутивы Python в каталог dist/ в PyPI. Этот текст предлагает минималистичный обзор использования. Более подробное руководство можно найти в руководстве по PyPA.
Если у вас есть какие-либо отзывы относительно конкретных версий действий, оставляйте комментарии в соответствующих обсуждениях объявлений для каждого выпуска.
master ветвь заката Версия master ветки устарела. Пожалуйста, измените используемую вами версию GitHub Action с master на release/v1 или используйте точный тег или дайте согласие на использование полного SHA фиксации Git и Dependabot.
Примечание
В настоящее время надежную публикацию нельзя использовать в повторно используемом рабочем процессе. Вместо этого рекомендуется создать одноразовый рабочий процесс, содержащий задание, вызывающее ваш многоразовый рабочий процесс, а затем выполнить шаг доверенной публикации из отдельного задания в этом одноразовом рабочем процессе. Альтернативно вы все равно можете использовать имя пользователя/токен внутри многократно используемого рабочего процесса.
Примечание
Доверенную публикацию иногда называют по лежащей в ее основе технологии — OpenID Connect или сокращенно OIDC. Если вы видите ссылки на «публикацию OIDC» в контексте PyPI, значит, они имеют в виду именно это.
Этот пример сразу переходит к современной лучшей практике. Если вы хотите использовать токены 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 # ВАЖНО: это разрешение является обязательным для доверенных шагов публикации: # получить ваши дистрибутивы здесь-имя: Публикация дистрибутивов пакетов в PyPI использует: pypa/gh-action-pypi-publish@release/v1
Примечание
Совет для профессионалов: вместо использования указателей ветвей, таких как unstable/v1 , прикрепите версии Actions, которые вы используете, к помеченным версиям или идентификаторам фиксации sha1. Это сделает ваши рабочие процессы более безопасными и лучше воспроизводимыми, избавив вас от неожиданных и неприятных сюрпризов.
Также можно использовать другие индексы, поддерживающие надежную публикацию, например TestPyPI:
- имя: Публикация дистрибутивов пакетов в TestPyPI. использует: pypa/gh-action-pypi-publish@release/v1 с: URL-адрес репозитория: https://test.pypi.org/legacy/
(не забудьте обновить имя среды на testpypi или подобное!)
Примечание
Совет для профессионалов: устанавливайте разрешение id-token: write только в задании, которое выполняет публикацию, а не глобально. Кроме того, постарайтесь отделить сборку от публикации — это гарантирует, что любые сценарии, злонамеренно внедренные в среду сборки или тестирования, не смогут повысить привилегии, оставаясь незамеченными.
Распространенным вариантом использования является загрузка пакетов только при помеченном коммите, для этого добавьте к заданию фильтр:
if: github.event_name == 'push' && BeginsWith(github.ref, 'refs/tags')
Важный
Поддержка создания и загрузки цифровых аттестаций в настоящее время является экспериментальной и ограничивается только потоками доверенной публикации с использованием PyPI или TestPyPI. Поддержка этой функции пока не стабильна; описанные ниже настройки и поведение могут быть изменены без предварительного уведомления.
Примечание
Создание и загрузка цифровых аттестаций в настоящее время требует аутентификации у доверенного издателя.
Создание подписанных цифровых аттестаций для всех файлов дистрибутива и их совместная загрузка теперь включена по умолчанию для всех проектов, использующих Trusted Publishing. Чтобы отключить его, установите attestations следующим образом:
с: подтверждения: ложь
Объекты аттестации создаются с помощью Sigstore для каждого пакета распространения, подписывая их удостоверением, предоставленным токеном OIDC GitHub, связанным с текущим рабочим процессом. Это означает, что и доверенная аутентификация публикации, и аттестации привязаны к одному и тому же удостоверению.
Это действие GitHub не имеет ничего общего с созданием дистрибутивов пакетов . Пользователи несут ответственность за подготовку дистрибутивов к загрузке, помещая их в папку dist/ перед выполнением этого Действия.
Важный
Поскольку это действие GitHub основано на Docker, его можно использовать только из заданий на базе GNU/Linux в рабочих процессах GitHub Actions CI/CD. Это задумано и вряд ли изменится по ряду соображений, на которые мы полагаемся.
Однако это не должно мешать публиковать дистрибутивы для конкретных платформ. Настоятельно рекомендуется отделить задания по созданию колес для конкретной ОС от задания публикации. Это позволяет (1) протестировать точно те же артефакты, которые собираются загрузить в PyPI, (2) предотвратить асинхронную публикацию параллельными несинхронизированными заданиями только части дистрибутивов (в случае, если часть заданий завершается неудачно, а другие завершаются успешно). с неполным выпуском PyPI) и (3) выполнить атомарную загрузку в PyPI (когда часть дистов появляется в PyPI, установщики, такие как pip, будут использовать эту версию для разрешения зависимостей, но это может привести к тому, что в некоторых средах использовать sdists, пока колесо для их среды выполнения еще не доступно).
Чтобы реализовать такую оркестровку, используйте действия 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
с:паролем: ${{ secrets.TEST_PYPI_API_TOKEN }}URL-репозитория: https://test.pypi.org/legacy/ Вы можете изменить целевой каталог по умолчанию для dist/ на любой каталог по вашему вкусу. Вызов действия теперь будет выглядеть так:
- имя: Опубликовать пакет в PyPI. использует: pypa/gh-action-pypi-publish@release/v1 с: packages-dir: custom-dir/
Рекомендуется запускать twine check сразу после создания файлов, но при этом twine check также выполняется перед загрузкой. Вы также можете отключить проверку шпагата с помощью:
с: проверить метаданные: ложь
Иногда, когда вы публикуете релизы из нескольких мест, ваш рабочий процесс может столкнуться с состоянием гонки. Например, при публикации из нескольких ЭК или даже при наличии рабочих процессов с одинаковыми шагами, запускаемых в CI/CD GitHub Actions для разных событий, касающихся одного и того же действия высокого уровня.
Чтобы облегчить этот вариант использования, вы можете использовать настройку skip-existing (отключенных по умолчанию) следующим образом:
с: пропустить-существующий: правда
Примечание
Совет для профессионалов: старайтесь не включать этот параметр, где это возможно. Если у вас есть шаги для публикации как в PyPI, так и в TestPyPI, рассмотрите возможность использования его только для последнего, поскольку первый из них громко терпит неудачу при наличии дубликатов.
Иногда twine upload может завершиться неудачно, и для отладки используйте verbose параметр следующим образом:
с: многословный: правда
Возможно, вы захотите проверить, были ли файлы в PyPI автоматически загружены сценарием CI. Он покажет значения SHA256, MD5, BLAKE2-256 файлов, которые будут загружены.
с: print-hash: true
Значение имени пользователя по умолчанию — __token__ . Если вы публикуете данные в специальном реестре, который не предоставляет токены API, например devpi , вам может потребоваться указать собственную пару имени пользователя и пароля. Вот как это делается.
с:пользователем: guidopassword: ${{ secrets.DEVPI_PASSWORD }} Секрет, используемый в ${{ secrets.DEVPI_PASSWORD }} необходимо создать на странице среды в настройках вашего проекта на GitHub. См. Создание и использование секретов.
Раньше при публикации в PyPI наиболее безопасным способом определения области доступа для автоматической публикации было использование функции токенов API PyPI. Можно было бы сделать его частью проекта и сохранить как секрет, привязанный к среде, в настройках репозитория GitHub, назвав его, например, ${{ secrets.PYPI_API_TOKEN }} . См. Создание и использование секретов. Несмотря на то, что доверенная публикация по-прежнему безопасна, теперь поощряется использование токенов API как передовая практика на поддерживаемых платформах (например, GitHub).
Dockerfile и связанные с ним сценарии и документация в этом проекте выпускаются под лицензией BSD с тремя пунктами.
