Выпуск и обслуживание действий

Введение

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

• Использует GitHub Actions для непрерывной интеграции, обновлений зависимостей, управления выпусками и автоматизации задач.
• Обеспечивает надежность с помощью автоматических тестов и индикаторов сборки.
• Указывает, как можно использовать действие, желательно в рамках более широкого рабочего процесса.
• Сообщите, какой тип вкладов от участников сообщества вы приветствуете. (Например, проблемы, запросы на вытягивание или отчеты об уязвимостях.)

Пример применения этого процесса см. в разделе actions/javascript-action.

Разработка и выпуск действий

В этом разделе мы рассмотрим пример процесса разработки и выпуска действий и покажем, как использовать GitHub Actions для его автоматизации.

Сведения о действиях JavaScript

Действия JavaScript — это репозитории Node.js с метаданными. Однако действия JavaScript имеют дополнительные свойства по сравнению с традиционными проектами Node.js:

• Зависимые пакеты фиксируются вместе с кодом, обычно в скомпилированной и минифицированной форме. Это означает, что автоматизированные сборки и безопасные вклады сообщества важны.

• Выпуски с тегами можно публиковать непосредственно в GitHub Marketplace и использовать в рабочих процессах в GitHub.

• Многие действия используют программные интерфейсы GitHub и сторонние API, поэтому мы рекомендуем комплексное тестирование.

Настройка рабочих процессов GitHub Actions

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

1. Добавьте рабочий процесс, который активируется при отправке фиксации в ветвь компонента или в main, а также при создании запроса на вытягивание. Настройте рабочий процесс, чтобы он выполнял модульные и интеграционные тесты. В качестве примера ознакомьтесь с этим рабочим процессом.

2. Добавьте рабочий процесс, который активируется при публикации или редактировании выпуска. Настройте рабочий процесс, чтобы обеспечить наличие семантических тегов. Вы можете использовать действие, например JasonEtco/build-and-tag-action, для компиляции и объединения файла JavaScript и метаданных, а также принудительной отправки семантических тегов основных версий, дополнительных версий и исправлений. Дополнительные сведения о семантических тегах см. в разделе "О семантике управления версиями".

   Примечание.

   Если включить неизменяемые выпуски для репозитория, это действие нельзя использовать для принудительная отправка тегов, привязанных к выпускам на GitHub. Сведения об управлении выпусками с неизменяемыми выпусками см. в статье Использование неизменяемых выпусков и тегов для управления выпусками действия.

Пример процесса разработчика

Ниже приведен пример процесса, который можно выполнить автоматически для выполнения тестов, создания выпуска и публикации в GitHub Marketplace, а также публикации действия.

1. Работайте с функциями в ветках по потоку GitHub. Дополнительные сведения см. в разделе GitHub flow.

   • При отправке фиксации в ветвь функции рабочий процесс тестирования будет автоматически выполнять тесты.

2. Создавайте запросы на вытягивание из ветви main, чтобы инициировать обсуждение и проверку, а по завершении выполните слияние ветви.

   • При открытии запроса на вытягивание из ветви или вилки рабочий процесс тестирования снова выполнит тесты, на этот раз с фиксацией слияния.

   •      **Примечание.** По соображениям безопасности рабочие процессы, активированные `pull_request` из вилок, имеют ограниченные разрешения `GITHUB_TOKEN` и не имеют доступа к секретам. Если тесты или другие рабочие процессы, активированные при запросе на вытягивание, требуют доступа к секретам, рассмотрите возможность использования другого события, например [ручного триггера](/actions/using-workflows/events-that-trigger-workflows#manual-events) или [`pull_request_target`](/actions/using-workflows/events-that-trigger-workflows#pull_request_target). Дополнительные сведения см. в разделе [AUTOTITLE](/actions/using-workflows/events-that-trigger-workflows#pull-request-events-for-forked-repositories).
     

3. Создайте выпуск с семантическими тегами. Вы также можете опубликовать в GitHub Marketplace с помощью простого флажка. Дополнительные сведения см. в разделе Управление выпусками в репозитории и Публикация действий в GitHub Marketplace.

   • При публикации или изменении выпуска рабочий процесс выпуска будет автоматически выполнять компиляцию и настройку тегов.

   • Рекомендуем создавать выпуски с использованием тегов с семантическими версиями, например v1.1.3, и сохранять теги основной версии (v1) и дополнительной версии (v1.1) в соответствии с последней успешной фиксацией. Дополнительные сведения см. в разделе Управление пользовательскими действиями и О семантической версии.

Результаты

В отличие от некоторых других стратегий автоматического управления выпусками, этот процесс намеренно не фиксирует зависимости в ветви main, а только в фиксации выпусков с тегами. Таким образом, вы призываете пользователей вашего действия ссылаться на именованные теги или sha, и помогаете обеспечить безопасность сторонних запросов на вытягивание, выполняя сборку самостоятельно во время выпуска.

Использование семантических выпусков означает, что пользователи ваших действий могут закрепить рабочие процессы в версии и знать, что они могут продолжать получать последние стабильные, не критически важные функции в зависимости от их уровня комфорта.

Работа с сообществом

GitHub предоставляет инструменты и руководства, которые помогут вам работать с open source сообществом. Ниже приведено несколько средств, которые рекомендуется настроить для эффективной двухсторонней связи. Предоставляя следующие сигналы сообществу, вы побуждаете других пользователей использовать и изменять ваше действие и вносить свой вклад в его разработку:

• Приводите в README большое количество примеров использования и рекомендаций. Дополнительные сведения см. в разделе Сведения о файле README репозитория.
• Включите значок состояния рабочего процесса в файл README. Дополнительные сведения см. в разделе Добавление эмблемы состояния рабочего процесса. Кроме того, посетите shields.io, чтобы узнать о других значках, которые можно добавить.
• Добавьте файлы с правилами взаимодействия и работы членов сообщества, такие как CODE_OF_CONDUCT, CONTRIBUTING и SECURITY. Дополнительные сведения см. в разделе Создание файла работоспособности сообщества по умолчанию..
• Сохраняйте текущие проблемы, используя такие действия, как действия или устаревшие действия.

Дополнительные материалы

Примеры, в которых используются аналогичные шаблоны:

•         [github/super-linter](https://github.com/github/super-linter)
  

•         [octokit/request-action](https://github.com/octokit/request-action)
  

•         [actions/javascript-action](https://github.com/actions/javascript-action)