Блог

Я заметил, что в различных примерах рабочего процесса действий GitHub часто при вызове предопределенного действия (с uses: синтаксисом) указывается конкретная версия этого действия. Например:

 steps:
    - uses: actions/checkout@v2
    - name: Set up Python
      uses: actions/setup-python@v2
      with:
        python-version: '3.x'
 

Приведенный выше рабочий процесс указывает @v2 для обоих actions/checkout и actions/setup-python .

Вопрос в том, как узнать, что @v2 это лучшая версия для использования?
И как я узнаю, когда @v3 станет доступно?

Еще более запутанным является случай действия, используемого для публикации в pypi, pypa/gh-action-pypi-publish . В примерах, которые я рассмотрел, я видел, как минимум, четыре разные версии, указанные:

• pypa/gh-action-pypi-publish@27b31702a0e7fc50959f5ad993c78deac1bdfc29
• pypa/gh-action-pypi-publish@master
• pypa/gh-action-pypi-publish@v1
• pypa/gh-action-pypi-publish@release/v1

Как мне узнать, какую из них использовать?И вообще, как вы узнаете, какие из них доступны, и в чем различия?

Как узнать, какую версию использовать?

При написании рабочего процесса и включении действия я рекомендую посмотреть вкладку Release в репозитории GitHub. Для actions/setup-python этого было бы https://github.com/actions/setup-python/releases

На этой странице вы должны увидеть, какие существуют версии и какая из них последняя. Вы хотите использовать последнюю версию, потому что таким образом вы можете быть уверены, что не отстаете, и обновление не станет слишком болезненным в будущем.

Как ссылаться на версию?

По соглашению действия публикуются с определенными тегами (например v1.0.1 , ), а также с основным тегом (например v1 , ). Это позволяет вам ссылаться на действие, подобное so actions/setup-python@v1 . Как только версия v1.0.2 будет опубликована, вы автоматически будете использовать ее. Это означает, что вы получаете выгоду от исправлений ошибок и новых функций, но не можете вносить критические изменения.

Однако обратите внимание, что это только по соглашению. Не каждый автор действия публикует основной тег и перемещает его по мере публикации новых тегов. Кроме того, автор может внести критическое изменение, не затрагивая основную версию.

Когда использовать другие форматы

Как вы сказали, есть и другие способы, которыми вы можете ссылаться на действие, такое как конкретная фиксация (например actions/setup-python@27b31702a0e7fc50959f5ad993c78deac1bdfc29 ) и другие.

В общем, вы хотите придерживаться тегов, как описано выше. В частности, ссылка @main на or @master опасна, потому что вы всегда будете получать последние изменения, которые могут нарушить ваш рабочий процесс. Если есть действие, которое рекомендует вам ссылаться на их ветку по умолчанию, и они не публикуют теги, я рекомендую создать проблему в их репозитории GitHub с просьбой опубликовать теги.

Использование хэша git может быть полезно, если вам нужно использовать определенную версию. Примером использования может быть то, что вы хотите проверить, исправит ли конкретная версия проблему, или если вы видите, что автор действия внес некоторые новые коммиты с изменениями, которые еще не помечены. Затем вы можете протестировать эту версию действия.

Безопасность

С точки зрения безопасности использование тега (например @v1 , или @v1.1.0 ) или ветки (например @main ) проблематично, поскольку автор этого репозитория может изменить, на что он ссылается. Злонамеренный автор действия может добавить вредоносный код в эту ветку или даже просто быть недостаточно осторожным при проверке PR и тем самым ввести уязвимость (например, через транзитивную зависимость).

Используя хэши (например @27b31702a0e7fc50959f5ad993c78deac1bdfc29 ), вы точно знаете, что получаете, и это не изменится, если вы не решите изменить версию, обновив хэш (после чего вы можете внимательно просмотреть изменения).

По состоянию на начало 2022 года использование хэшей вместо тегов не получило широкого распространения, но, например, GitHub делает это для своего репозитория docs. Поскольку безопасность цепочки поставок становится все более важной, создаются инструменты, помогающие с «закреплением» (указывают на конкретную версию по хэшу, а не по тегу), такие как sethvargo / ratchet. Но даже depedanbot (см. Ниже) должен иметь возможность обновлять хэши до последнего хэша.

Как узнать, когда появится новая версия?

Для этого вы можете использовать Dependabot: обновлять свои действия с помощью Dependabot. Dependabot — это инструмент, который создает запрос на извлечение в вашем репозитории, как только доступна новая версия любого из ваших действий, чтобы вы могли просматривать изменения и обновлять свой рабочий процесс.

Вот пример конфигурации Dependabot, которая поддерживает ваши действия в актуальном состоянии путем создания PR:

 version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "daily"
 

Люди должны привыкнуть к такому управлению выпусками на основе тегов (другие примеры, такие как Docker), как описано в подобных статьях.

Как пользователь узнает, какой тег использовать? Обычно файл документации к действию содержит рекомендуемую версию для использования, поэтому 99% пользователей должны следовать ей. Вам нужно использовать другие теги, только если вы хотите жить на переднем крае.