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

Введение

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

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

Пример этого процесса см. здесь: github-developer/javascript-action.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   • Примечание. По соображениям безопасности рабочие процессы, активированные pull_request из вилок, имеют ограниченные разрешения GITHUB_TOKEN и не имеют доступа к секретам. Если тесты или другие рабочие процессы, активированные при запросе на вытягивание, требуют доступа к секретам, рассмотрите возможность использования другого события, например ручного триггера или pull_request_target. Дополнительные сведения см. здесь.

3. Создайте выпуск с семантическими тегами. Дополнительные сведения см. в разделах Управление выпусками в репозитории.

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

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

Результаты

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

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

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

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

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

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

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

• github/super-linter
• octokit/request-action
• github-developer/javascript-action