Сведения о настраиваемых действиях

Вы можете создавать действия путем написания специального кода, взаимодействующего с репозиторием любым желательным вам способом, включая интеграцию с API-интерфейсами GitHub и любым общедоступным сторонним API. Например, действие может публиковать модули NPM, отправлять SMS-оповещения при возникновении неотложных проблем или развертывать готовый код.

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

Действия можно выполнять непосредственно на компьютере или в контейнере Docker. Вы можете определить входные и выходные данные, а также переменные среды для действия.

Типы действий

Вы можете создавать контейнер Docker, JavaScript и составные действия. Для действий требуется файл метаданных, чтобы определить входные и выходные данные, а также основную точку входа для действия. Файл метаданных должен иметь имя action.yml либо action.yaml. Дополнительные сведения см. в разделе Синтаксис метаданных для GitHub Actions.

Тип	Linux	macOS	Windows
Контейнер Docker
JavaScript
Составные действия

Действия контейнера Docker

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

Контейнер Docker позволяет использовать определенные версии операционной системы, зависимостей, средств и кода. Для действий, которые должны выполняться в определенной конфигурации среды, Docker является оптимальным вариантом, так как позволяет настроить операционную систему и средства. Из-за задержки при создании и извлечении контейнера действия контейнера Docker выполняются медленнее, чем действия JavaScript.

Действия контейнера Docker могут выполняться только в средствах выполнения с операционной системой Linux. В локальных средствах выполнения должна использоваться операционная система Linux и должен быть установлен Docker для выполнения действий с контейнерами Docker. Дополнительные сведения о требованиях локальных средств выполнения см. в разделе "О самостоятельно размещенных средствах выполнения".

Действия JavaScript

Действия JavaScript могут выполняться непосредственно на компьютере со средством выполнения тестов и отделять код действия от среды, используемой для выполнения такого кода. Использование действия JavaScript упрощает код действия и позволяет ему выполняться быстрее действия контейнера Docker.

Чтобы обеспечить совместимость действий JavaScript со всеми средствами выполнения, размещенными в GitHub (Ubuntu, Windows и macOS), упакованный код JavaScript должен быть чистым JavaScript без зависимостей от других двоичных файлов. Действия JavaScript запускаются непосредственно в средстве выполнения и используют двоичные файлы, которые уже существуют в образе средства выполнения тестов.

Если вы разрабатываете проект Node.js, набор средств GitHub Actions предоставляет пакеты, которые можно использовать в проекте для ускорения разработки. Дополнительные сведения см. в репозитории actions/toolkit.

Составные действия

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

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

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

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

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

Если вы создаете действие, которое не планируете делать доступным для других пользователей, вы можете хранить файлы этого действия в любом расположении своего репозитория. Если вы планируете объединить действие, рабочий процесс и код приложения в одном репозитории, рекомендуется хранить действия в каталоге .github. Например, .github/actions/action-a и .github/actions/action-b.

Обеспечение совместимости с другими платформами

Многие пользователи получают доступ к GitHub в домене, отличном от GitHub.com, например GHE.com или личного домена для GitHub Enterprise Server.

Чтобы убедиться, что действие совместимо с другими платформами, не используйте жестко закодированные ссылки на URL-адреса API, например https://api.github.com. Вместо этого можно:

Используйте переменные среды (см. "AUTOTITLE"):
- Для REST API используйте переменную среды GITHUB_API_URL.
- Для GraphQL используйте переменную среды GITHUB_GRAPHQL_URL.
Используйте набор средств, например @actions/github, который может автоматически задать правильные URL-адреса.

Использование управления выпусками для действий

В этом разделе объясняется, как использовать управление выпусками, чтобы обеспечить предсказуемое распространение обновлений для действий.

Использование тегов для управления выпусками

Мы рекомендуем использовать теги для управления выпусками действий. С помощью этого подхода пользователи могут легко различать основной и дополнительный номера версии:

Создайте и проверьте выпуск в ветви выпуска (например, release/v1) перед созданием тега выпуска (например, v1.0.2).
Создайте выпуск с помощью семантического версионирования. Дополнительные сведения см. в разделе Управление выпусками в репозитории.
Перемещайте тег основной версии (например v1, v2) чтобы указать ссылку на Git текущего выпуска. Дополнительные сведения см. в разделе Основы Git — расстановка тегов.
Вводите новый тег основной версии (v2) для изменений, которые будут нарушить существующие рабочие процессы. Например, изменение входных данных действия будет критическим изменением.
Основные номера версии могут быть первоначально выпущены с тегом beta, чтобы указать их состояние, например, v2-beta. Затем, когда все будет готово, тег -beta можно удалить.

В этом примере показано, как пользователь может ссылаться на тег основного выпуска:

steps:
    - uses: actions/javascript-action@v1

В этом примере показано, как пользователь может ссылаться на тег определенного выпуска исправления:

steps:
    - uses: actions/[email protected]

Использование ветвей для управления выпусками

Если вы предпочитаете использовать имена ветвей для управления выпусками, в этом примере показано, как ссылаться на именованную ветвь:

steps:
    - uses: actions/javascript-action@v1-beta

Использование SHA фиксации для управления выпусками

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

steps:
    - uses: actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f

Создание файла сведений для действия

Мы рекомендуем создать файл сведений, чтобы помочь людям понять, как следует использовать ваше действие. В файл README.md можно включить следующее:

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

Сравнение GitHub Actions с GitHub Apps

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

Преимущества GitHub Actions и GitHub Apps

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

GitHub Apps:

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

GitHub Actions:

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

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

"Команды рабочего процесса для GitHub Actions"

Сведения о настраиваемых действиях

В этой статье