Note
GitHubразмещенные в данный момент средства выполнения не поддерживаются в GitHub Enterprise Server. Дополнительные сведения о планируемой поддержке в будущем см. в GitHub public roadmap.
Сведения о синтаксисе YAML для рабочих процессов
Файлы рабочего процесса используют синтаксис YAML и должны иметь расширение файла .yml
или .yaml
. Если вы не знакомы с YAML и хотите узнать о нем подробнее, см. раздел Узнайте о YAML за Y минут.
Файлы рабочего процесса необходимо хранить в каталоге .github/workflows
репозитория.
name
Имя рабочего процесса. GitHub отображает имена рабочих процессов на вкладке "Действия" репозитория. Если не указано name
, GitHub отображает путь к файлу рабочего процесса относительно корневого каталога репозитория.
run-name
Имя рабочего процесса, созданное из рабочего процесса. GitHub отображает имя запуска рабочего процесса в списке рабочих процессов, выполняемых на вкладке "Действия" репозитория. Если run-name
опущено или только пробелы, то для запуска рабочего процесса задано имя запуска для конкретного события. Например, для рабочего процесса, активированного событием push
или событием, оно устанавливается как сообщение фиксации или pull_request
название запроса на вытягивание.
Это значение может включать выражения и может ссылаться на github
них и inputs
контексты.
Пример run-name
run-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }}
on
Чтобы автоматически активировать рабочий процесс, используйте on
для указания событий, которые могут привести к запуску рабочего процесса. Список доступных событий см. в разделе "События, инициирующие рабочие процессы".
Можно определить одно или несколько событий, которые могут активировать рабочий процесс или задать расписание времени. Можно также настроить рабочий процесс так, чтобы он выполнялся только для определенных файлов, тегов или изменений ветвей. Описание этих параметров приводится в следующих разделах.
Использование одного события
Например, рабочий процесс со следующим значением on
будет выполняться при осуществлении отправки в любую ветвь в репозитории рабочего процесса:
on: push
Использование нескольких событий
Можно указать одно или несколько событий. Например, рабочий процесс со следующим значением on
будет выполняться при осуществлении отправки в любую ветвь в репозитории, или когда кто-то создает вилку репозитория:
on: [push, fork]
Если указано несколько событий, для активации рабочего процесса необходимо, чтобы произошло только одно из них. Если одновременно происходят несколько событий, активирующих рабочий процесс, будет активировано несколько выполнений рабочих процессов.
Использование типов действий
Некоторые события имеют типы действий, позволяющие лучше контролировать выполнение рабочего процесса. Используйте on.<event_name>.types
для определения типа действия для события, которое активирует запуск рабочего процесса.
Например, событие issue_comment
имеет типы действий created
, edited
и deleted
. Если рабочий процесс активируется в событии label
, он будет выполняться при создании, изменении или удалении метки. Если указать тип действия created
для события label
, рабочий процесс будет запускаться при создании метки, но не при изменении или удалении метки.
on:
label:
types:
- created
Если указать несколько типов действий, для активации рабочего процесса потребуется выполнить только один из этих типов действий. Если одновременно происходят несколько типов действий для событий, активирующих рабочий процесс, будет активировано несколько выполнений рабочих процессов. Например, следующий рабочий процесс активируется при открытии проблемы или добавлении для нее метки. Если открывается проблема с двумя метками, начинаются три запуска рабочего процесса: один для события открытия проблемы и два для двух событий проблем с метками.
on:
issues:
types:
- opened
- labeled
Дополнительные сведения о каждом событии и их типах действий см. в разделе "События, инициирующие рабочие процессы".
Использование фильтров
Некоторые события имеют фильтры, позволяющие лучше контролировать выполнение рабочего процесса.
Например, событие push
имеет фильтр branches
, из-за которого рабочий процесс выполняется только при отправке в ветвь, которая соответствует фильтру branches
, а не при любой отправке.
on:
push:
branches:
- main
- 'releases/**'
Использование типов действий и фильтров с несколькими событиями
Если вы указываете типы действий или фильтры для события и триггеры рабочего процесса для нескольких событий, необходимо настроить каждое событие отдельно. Необходимо добавить двоеточие (:
) ко всем событиям, включая события без конфигурации.
Например, рабочий процесс со следующим значением on
будет выполняться в следующих случаях:
- создание метки;
- отправка в ветвь
main
в репозитории; - отправка в ветвь с поддержкой GitHub Pages.
on:
label:
types:
- created
push:
branches:
- main
page_build:
on.<event_name>.types
Используйте on.<event_name>.types
для определения типа действия для события, которое активирует выполнение рабочего процесса. Большинство событий GitHub активируются несколькими типами действий. Например, label
активируется, если метка имеет значение created
, edited
или deleted
. Ключевое слово types
позволяет сузить действие, которое приводит к выполнению рабочего процесса. Если только один тип действия активирует событие веб-перехватчика, ключевое слово types
не требуется.
Можно использовать массив событий types
. Дополнительные сведения о каждом событии и их типах действий см. в разделе "События, инициирующие рабочие процессы".
on:
label:
types: [created, edited]
on.<pull_request|pull_request_target>.<branches|branches-ignore>
При использовании событий pull_request
и pull_request_target
можно настроить выполнение рабочего процесса только для запросов на вытягивание, предназначенных для конкретных ветвей.
Используйте фильтр branches
, если требуется включить шаблоны имен ветвей или как включить, так и исключить их. Используйте фильтр branches-ignore
, если требуется только исключить шаблоны имен ветвей. Для одного и того же события в рабочем процессе нельзя использовать фильтры branches
и branches-ignore
одновременно.
Если вы определили и branches
/branches-ignore
, и paths
/paths-ignore
, рабочий процесс будет запускаться только в случае, если выполнены оба фильтра.
Ключевые слова branches
и branches-ignore
принимают стандартные маски, использующие такие символы, как *
, **
, +
, ?
, !
и другие, чтобы соответствовать нескольким именам ветвей. Если имя содержит любой из этих символов и требуется буквальное совпадение, необходимо экранировать каждый из этих специальных символов с помощью \
. Дополнительные сведения о шаблонах глобов см. в разделе "Синтаксис рабочего процесса для GitHub Actions".
Пример: включение ветвей
Шаблоны, определенные в branches
, оцениваются по имени ссылки Git. Например, указанный ниже рабочий процесс будет выполняться всякий раз, когда происходит событие pull_request
для запроса на вытягивание, нацеленного на:
- ветви с именем
main
(refs/heads/main
); - ветви с именем
mona/octocat
(refs/heads/mona/octocat
); - ветви, имя которой начинается с
releases/
, напримерreleases/10
(refs/heads/releases/10
);
on:
pull_request:
# Sequence of patterns matched against refs/heads
branches:
- main
- 'mona/octocat'
- 'releases/**'
Не следует использовать фильтрацию путей или ветвей, чтобы пропустить выполнение рабочего процесса, если рабочий процесс является обязательным. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Пропуск запусков рабочих процессов](/actions/using-workflows/required-workflows)".
Если рабочий процесс пропускается из-за фильтрации ветвей, фильтрации путей или сообщения фиксации, то проверки, связанные с этим рабочим процессом, останутся в состоянии "Ожидание". Запрос на включение внесенных изменений, требующий успешной проверки, будет заблокирован при слиянии.
Пример исключения ветвей
В случае соответствия шаблона branches-ignore
рабочий процесс не будет выполняться. Шаблоны, определенные в branches-ignore
, оцениваются по имени ссылки Git. Например, указанный ниже рабочий процесс будет выполняться всякий раз, когда происходит событие pull_request
, если при этом запрос на вытягивание не нацелен на:
- ветви с именем
mona/octocat
(refs/heads/mona/octocat
); - ветви, имя которой соответствует
releases/**-alpha
, напримерreleases/beta/3-alpha
(refs/heads/releases/beta/3-alpha
);
on:
pull_request:
# Sequence of patterns matched against refs/heads
branches-ignore:
- 'mona/octocat'
- 'releases/**-alpha'
Пример: включение и исключение ветвей
Нельзя использовать branches
и branches-ignore
для фильтрации одного и того же события в одном рабочем процессе. Если вам нужно с помощью шаблонов одновременно включить и исключить имена ветвей для одного события, используйте фильтр branches
с символом !
, чтобы указать, какие ветви следует исключить.
Если вы определяете ветвь с символом !
, необходимо также определить по крайней мере одну ветвь без символа !
. Если вы хотите только исключить ветви, используйте вместо этого branches-ignore
.
Порядок определения шаблонов имеет значение.
- Соответствующий отрицательный шаблон (с префиксом
!
) после положительного совпадения исключает ссылку Git. - Соответствующий положительный шаблон после отрицательного совпадения снова включает ссылку Git.
Указанный ниже рабочий процесс будет выполняться на событиях pull_request
для запросов на вытягивание, нацеленных на releases/10
или releases/beta/mona
, но не для запросов на вытягивание, нацеленных на releases/10-alpha
или releases/beta/3-alpha
, потому что отрицательный шаблон !releases/**-alpha
соответствует положительному шаблону.
on:
pull_request:
branches:
- 'releases/**'
- '!releases/**-alpha'
on.push.<branches|tags|branches-ignore|tags-ignore>
Пример. Включение ветвей и тегов
Шаблоны, определенные в branches
и tags
, применяются для имени ссылки Git. Например, следующий рабочий процесс будет выполняться всякий раз, когда событие push
происходит в:
- ветви с именем
main
(refs/heads/main
); - ветви с именем
mona/octocat
(refs/heads/mona/octocat
); - ветви, имя которой начинается с
releases/
, напримерreleases/10
(refs/heads/releases/10
); - теге с именем
v2
(refs/tags/v2
); - теге, имя которого начинается с
v1.
, напримерv1.9.1
(refs/tags/v1.9.1
).
on:
push:
# Sequence of patterns matched against refs/heads
branches:
- main
- 'mona/octocat'
- 'releases/**'
# Sequence of patterns matched against refs/tags
tags:
- v2
- v1.*
Пример. Исключение ветвей и тегов
Пример. Включение и исключение ветвей и тегов
Вы не можете использовать branches
и branches-ignore
для фильтрации одного и того же события в одном рабочем процессе. Аналогично, вы не можете использовать tags
и tags-ignore
для фильтрации одного и того же события в одном рабочем процессе. Если вы хотите одновременно включить и исключить шаблоны ветвей или тегов для одного события, используйте фильтр branches
или tags
с символом !
, чтобы указать, какие ветви или теги следует исключить.
Если вы определяете ветвь с символом !
, необходимо также определить по крайней мере одну ветвь без символа !
. Если вы хотите только исключить ветви, используйте вместо этого branches-ignore
. Аналогично, если вы определяете тег с символом !
, необходимо также определить по крайней мере один тег без символа !
. Если вы хотите только исключить теги, используйте вместо этого tags-ignore
.
Порядок определения шаблонов имеет значение.
- Соответствующий отрицательный шаблон (с префиксом
!
) после положительного совпадения исключает ссылку Git. - Соответствующий положительный шаблон после отрицательного совпадения снова включает ссылку Git.
Следующий рабочий процесс будет выполняться при отправке в releases/10
или releases/beta/mona
, но не в releases/10-alpha
или releases/beta/3-alpha
, потому что за положительным шаблоном следует отрицательный шаблон !releases/**-alpha
.
on:
push:
branches:
- 'releases/**'
- '!releases/**-alpha'
on.<push|pull_request|pull_request_target>.<paths|paths-ignore>
При использовании событий push
и pull_request
можно настроить запускаемый рабочий процесс в зависимости от того, какие пути к файлам изменяются. Фильтры путей не оцениваются при отправке тегов.
Используйте фильтр paths
, если требуется включить шаблоны путей к файлам или одновременно включить и исключить их. Используйте фильтр paths-ignore
, если требуется только исключить шаблоны путей к файлам. Для одного и того же события в рабочем процессе нельзя использовать фильтры paths
и paths-ignore
одновременно. Если вы хотите включить и исключить шаблоны путей для одного события, используйте paths
префикс фильтра с !
символом, чтобы указать, какие пути следует исключить.
Note
Порядок определения paths
шаблонов имеет значение:
- Соответствующий отрицательный шаблон (с префиксом
!
) после положительного совпадения исключает путь. - Соответствующий положительный шаблон после отрицательного совпадения снова включает путь.
Если вы определили и branches
/branches-ignore
, и paths
/paths-ignore
, рабочий процесс будет запускаться только в случае, если выполнены оба фильтра.
Ключевые слова paths
и paths-ignore
принимают стандартные маски, в которых для соответствия нескольким именам путей используются подстановочные знаки *
и **
. Дополнительные сведения см. в разделе "Синтаксис рабочего процесса для GitHub Actions".
Пример. Включение путей
Если хотя бы один путь соответствует шаблону в фильтре paths
, рабочий процесс запускается. Например, приведенный ниже рабочий процесс будет выполняться при каждой отправке файла JavaScript (.js
).
on:
push:
paths:
- '**.js'
Не следует использовать фильтрацию путей или ветвей, чтобы пропустить выполнение рабочего процесса, если рабочий процесс является обязательным. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Пропуск запусков рабочих процессов](/actions/using-workflows/required-workflows)".
Если рабочий процесс пропускается из-за фильтрации путей, фильтрации ветвей или сообщения фиксации, то проверки, связанные с этим рабочим процессом, останутся в состоянии "Ожидание". Запрос на включение внесенных изменений, требующий успешной проверки, будет заблокирован при слиянии.
Пример. Исключение путей
Если все имена путей соответствуют шаблонам в paths-ignore
, рабочий процесс не запускается. Если хотя бы одно имя пути не соответствует шаблонам в paths-ignore
, рабочий процесс запускается.
Рабочий процесс с приведенным ниже фильтром пути будет выполняться только при событиях push
с по крайней мере одним файлом за пределами каталога docs
в корне репозитория.
on:
push:
paths-ignore:
- 'docs/**'
Пример. Включение и исключение путей
Нельзя использовать paths
и paths-ignore
для фильтрации одного и того же события в одном рабочем процессе. Если вы хотите включить и исключить шаблоны путей для одного события, используйте paths
префикс фильтра с !
символом, чтобы указать, какие пути следует исключить.
Если вы определяете путь с символом !
, необходимо также определить по крайней мере один путь без символа !
. Если вы хотите только исключить пути, используйте вместо этого paths-ignore
.
Порядок определения paths
шаблонов имеет значение:
- Соответствующий отрицательный шаблон (с префиксом
!
) после положительного совпадения исключает путь. - Соответствующий положительный шаблон после отрицательного совпадения снова включает путь.
Этот пример запускается каждый раз, когда событие push
включает файл в каталоге sub-project
или его подкаталогах, но не в каталоге sub-project/docs
. Например, принудительная отправка с изменением sub-project/index.js
или sub-project/src/index.js
запустит выполнение рабочего процесса, но принудительная отправка, изменяющая только sub-project/docs/readme.md
, не запустит его.
on:
push:
paths:
- 'sub-project/**'
- '!sub-project/docs/**'
Сравнение различий в GIT
Note
Если вы отправляете более 1000 фиксаций или если GitHub не создает дифф из-за времени ожидания, рабочий процесс всегда будет выполняться.
Фильтр определяет, должен ли запускаться рабочий процесс, оценивая измененные файлы и проверяя их по списку paths-ignore
или paths
. Если измененных файлов нет, рабочий процесс не запускается.
GitHub создает список измененных файлов, используя различия с двумя точками для push-уведомлений и с тремя точками — для запросов на вытягивание.
- Запросы на вытягивание. Различия с тремя точками — это сравнение последней версией тематической ветки с фиксацией, в которой тематическая ветка была в последний раз синхронизирована с основной ветвью.
- Отправки в существующие ветви. Различие с двумя точками — это сравнение головных и базовых значений SHA непосредственно друг с другом.
- Отправки в новые ветви. Различие с двумя точками в сравнении с родителем предка самой глубокой отправленной фиксации.
Различия ограничены 300 файлами. Если существуют соответствующие измененные файлы, которые не вошли в первые 300 файлов, возвращенных фильтром, рабочий процесс не запускается. Возможно, потребуется создать более узкие фильтры, чтобы рабочий процесс запускался автоматически.
Дополнительные сведения см. в разделе «Сравнение ветвей в запросе на вытягивание».
on.schedule
С помощью on.schedule
можно определить расписание рабочих процессов. Можно запланировать выполнение рабочего процесса в определенное время в формате UTC с помощью синтаксиса POSIX cron. Запланированные рабочие процессы запускаются в соответствии с последней фиксацией базовой ветви или ветви по умолчанию. Самый короткий интервал, с которым можно запускать запланированные рабочие процессы — 5 минут.
В этом примере рабочий процесс запускается каждый день в 5:30 и 17:30 (в формате UTC):
on:
schedule:
# * is a special character in YAML so you have to quote this string
- cron: '30 5,17 * * *'
Один рабочий процесс может запускаться несколькими событиями schedule
. Доступ к запланированному событию, при возникновении которого был запущен рабочий процесс, можно получить с помощью контекста github.event.schedule
. В этом примере рабочий процесс запускается с ежедневно с понедельника по четверг в 5:30 (в формате UTC), причем по понедельникам и средам шаг Not on Monday or Wednesday
пропускается.
on:
schedule:
- cron: '30 5 * * 1,3'
- cron: '30 5 * * 2,4'
jobs:
test_schedule:
runs-on: ubuntu-latest
steps:
- name: Not on Monday or Wednesday
if: github.event.schedule != '30 5 * * 1,3'
run: echo "This step will be skipped on Monday and Wednesday"
- name: Every time
run: echo "This step will always run"
Дополнительные сведения о синтаксисе cron см. в разделе "События, инициирующие рабочие процессы".
on.workflow_call
Используйте on.workflow_call
для определения входных и выходных данных для многократно используемого рабочего процесса. Вы также можете сопоставить секреты, доступные для вызываемого рабочего процесса. Дополнительные сведения о повторно используемых рабочих процессах см. в разделе Повторное использование рабочих процессов.
on.workflow_call.inputs
При использовании ключевого слова workflow_call
можно дополнительно указать входные данные, передаваемые вызываемому рабочему процессу из вызывающего рабочего процесса. Дополнительные сведения о ключевом слове workflow_call
см. в разделе События, инициирующие рабочие процессы.
Помимо доступных стандартных входных параметров on.workflow_call.inputs
требует параметр type
. Дополнительные сведения см. в разделе on.workflow_call.inputs.<input_id>.type
.
Если параметр default
не задан, значение по умолчанию для входных данных — false
для логического значения, 0
для числа и ""
для строки.
В вызываемом рабочем процессе можно использовать контекст inputs
для ссылки на входные данные. Дополнительные сведения см. в разделе Доступ к контекстной информации о запусках рабочих процессов.
Если вызывающий рабочий процесс передает входные данные, которые не указаны в вызываемом рабочем процессе, это приведет к ошибке.
Пример on.workflow_call.inputs
on:
workflow_call:
inputs:
username:
description: 'A username passed from the caller workflow'
default: 'john-doe'
required: false
type: string
jobs:
print-username:
runs-on: ubuntu-latest
steps:
- name: Print the input name to STDOUT
run: echo The username is ${{ inputs.username }}
Дополнительные сведения см. в разделе Повторное использование рабочих процессов.
on.workflow_call.inputs.<input_id>.type
Требуется, если входные данные определены для ключевого слова on.workflow_call
. Значение этого параметра — строка, указывающая тип входных данных. Должен иметь значение boolean
, number
или string
.
on.workflow_call.outputs
Карта выходных данных для вызываемого рабочего процесса. Выходные данные вызываемого рабочего процесса доступны для всех нижестоящих заданий в рабочем процессе вызывающего объекта. У каждых выходных данных есть идентификатор, необязательный description,
и value.
Для value
необходимо задать значение выходных данных из задания в рамках вызываемого рабочего процесса.
В приведенном ниже примере для этого многократно используемого рабочего процесса определяются два набора выходных данных: workflow_output1
и workflow_output2
. Они сопоставляются с выходными данными job_output1
и job_output2
из вызываемого заданияmy_job
.
Пример on.workflow_call.outputs
on:
workflow_call:
# Map the workflow outputs to job outputs
outputs:
workflow_output1:
description: "The first job output"
value: ${{ jobs.my_job.outputs.job_output1 }}
workflow_output2:
description: "The second job output"
value: ${{ jobs.my_job.outputs.job_output2 }}
Сведения о том, как ссылаться на выходные данные задания, см. в разделе jobs.<job_id>.outputs
. Дополнительные сведения см. в разделе Повторное использование рабочих процессов.
on.workflow_call.secrets
Карта секретов, которые можно использовать в вызываемом рабочем процессе.
В вызываемом рабочем процессе можно использовать контекст secrets
для ссылки на секрет.
Note
Если секрет передается в вложенный повторно используемый рабочий процесс, необходимо использовать jobs.<job_id>.secrets
еще раз для передачи секрета. Дополнительные сведения см. в разделе Повторное использование рабочих процессов.
Если вызывающий рабочий процесс передает секрет, который не указан в вызываемом рабочем процессе, это приведет к ошибке.
Пример on.workflow_call.secrets
on:
workflow_call:
secrets:
access-token:
description: 'A token passed from the caller workflow'
required: false
jobs:
pass-secret-to-action:
runs-on: ubuntu-latest
steps:
# passing the secret to an action
- name: Pass the received secret to an action
uses: ./.github/actions/my-action
with:
token: ${{ secrets.access-token }}
# passing the secret to a nested reusable workflow
pass-secret-to-workflow:
uses: ./.github/workflows/my-workflow
secrets:
token: ${{ secrets.access-token }}
on.workflow_call.secrets.<secret_id>
Строковый идентификатор, связанный с секретом.
on.workflow_call.secrets.<secret_id>.required
Логическое значение, указывающее, должен ли быть предоставлен секрет.
on.workflow_run.<branches|branches-ignore>
При использовании события workflow_run
можно указать, в каких ветвях должен выполняться запускающий рабочий процесс, чтобы активировать ваш рабочий процесс.
В фильтрах branches
и branches-ignore
можно использовать стандартные маски с такими символами, как *
, **
, +
, ?
, !
и другие, для сопоставления нескольких имен ветвей. Если имя содержит любой из этих символов, и требуется буквальное совпадение, необходимо экранировать каждый из этих специальных символов с помощью \
. Дополнительные сведения о шаблонах глобов см. в разделе "Синтаксис рабочего процесса для GitHub Actions".
Например, рабочий процесс со следующим триггером будет выполняться, только если рабочий процесс с именем Build
выполняется в ветви, имя которой начинается с releases/
.
on:
workflow_run:
workflows: ["Build"]
types: [requested]
branches:
- 'releases/**'
Рабочий процесс со следующим триггером будет выполняться, только если рабочий процесс с именем Build
выполняется в ветви с именем отличным от canary
.
on:
workflow_run:
workflows: ["Build"]
types: [requested]
branches-ignore:
- "canary"
Для одного и того же события в рабочем процессе нельзя использовать фильтры branches
и branches-ignore
одновременно. Если вам нужно с помощью шаблонов одновременно включить и исключить имена ветвей для одного события, используйте фильтр branches
с символом !
, чтобы указать, какие ветви следует исключить.
Порядок определения шаблонов имеет значение.
- Если после включающего шаблона идет исключающий (с префиксом
!
) и найдена ветвь, соответствующая им обоим, такая ветвь исключается. - Если после исключающего шаблона идет включающий, ветвь, соответствующая им обоим, снова включается.
Например, рабочий процесс со следующим триггером будет выполняться, если рабочий процесс с именем Build
выполняется в ветви с именем releases/10
или releases/beta/mona
, но не в ветви releases/10-alpha
, releases/beta/3-alpha
или main
.
on:
workflow_run:
workflows: ["Build"]
types: [requested]
branches:
- 'releases/**'
- '!releases/**-alpha'
on.workflow_dispatch
При использовании события workflow_dispatch
можно дополнительно указать входные данные, передаваемые рабочему процессу.
Этот триггер получает события только в том случае, если файл рабочего процесса находится на ветвь по умолчанию.
on.workflow_dispatch.inputs
Активированный рабочий процесс получает входные данные в контексте inputs
. Дополнительные сведения см. в статье Контексты.
Note
- Рабочий процесс также получит входные данные в контексте
github.event.inputs
. Информация в контекстеinputs
и в контекстеgithub.event.inputs
идентична, за исключением того, что контекстinputs
сохраняет логические значения в исходном формате логических значений, не преобразовывая их в строки. Типchoice
разрешается в строку и является одним вариантом выбора. - Максимальное число свойств верхнего уровня для
inputs
10. - Максимальная полезная нагрузка составляет
inputs
65 535 символов.
Пример on.workflow_dispatch.inputs
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'
type: choice
options:
- info
- warning
- debug
print_tags:
description: 'True to print to STDOUT'
required: true
type: boolean
tags:
description: 'Test scenario tags'
required: true
type: string
environment:
description: 'Environment to run tests against'
type: environment
required: true
jobs:
print-tag:
runs-on: ubuntu-latest
if: ${{ inputs.print_tags }}
steps:
- name: Print the input tag to STDOUT
run: echo The tags are ${{ inputs.tags }}
on.workflow_dispatch.inputs.<input_id>.required
Логическое значение, указывающее, нужно ли предоставлять входные данные.
on.workflow_dispatch.inputs.<input_id>.type
Значение этого параметра — строка, указывающая тип входных данных. Это должно быть одно из следующих: boolean
, number``choice``environment
или .string
permissions
permissions
можно использовать для изменения разрешений по умолчанию, предоставленных GITHUB_TOKEN
, при необходимости добавляя или удаляя права доступа, чтобы разрешить только минимальный требуемый доступ. Дополнительные сведения см. в разделе «Автоматическая проверка подлинности токенов».
permissions
можно использовать в качестве ключа верхнего уровня для применения ко всем заданиям в рабочем процессе или в конкретных заданиях. При добавлении ключа permissions
в конкретном задании указанные права доступа получают все действия и команды выполнения в этом задании, использующие GITHUB_TOKEN
. Дополнительные сведения см. в разделе jobs.<job_id>.permissions
.
Для каждого из доступных разрешений, показанных в таблице ниже, можно назначить один из уровней доступа: read
(если применимо), write
или none
. write
включает в себя read
. Если указать доступ для любого из этих разрешений, то для всех этих разрешений задано none
значение .
Доступные разрешения и подробные сведения о том, что позволяет выполнять действие:
Разрешение | Разрешает действие с помощью GITHUB_TOKEN |
---|---|
actions | Работа с GitHub Actions. Например, actions: write позволяет действию отменить выполнение рабочего процесса. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
checks | Работа с проверками запусков и контрольных наборов. Например, checks: write позволяет действию создать выполнение проверки. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
contents | Работа с содержимым репозитория. Например, contents: read позволяет действию перечислять фиксации и contents: write позволяет действию создавать выпуск. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
deployments | Работа с развертываниями. Например, deployments: write позволяет действию создать новое развертывание. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
discussions | Работа с обсуждениями GitHub. Например, discussions: write позволяет действию закрыть или удалить обсуждение. Дополнительные сведения см. в разделе «Использование API GraphQL для обсуждений». |
issues | Работа с проблемами. Например, issues: write позволяет действию добавить комментарий к проблеме. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
packages | Работа с пакетами GitHub. Например, packages: write позволяет действию отправлять и публиковать пакеты в пакетах GitHub. Дополнительные сведения см. в разделе «Сведения о разрешениях для пакетов GitHub». |
pages | Работа с GitHub Pages. Например, pages: write позволяет действию запрашивать сборку GitHub Pages. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
pull-requests | Работа с запросами на вытягивание. Например, pull-requests: write позволяет действию добавить метку в запрос на вытягивание. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
repository-projects | Работа с проектами GitHub (классическая модель). Например, repository-projects: write позволяет действию добавить столбец в проект (классическую модель). Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
security-events | Работа с проверкой кода GitHub и оповещениями Dependabot. Например, security-events: read позволяет выполнить действие для перечисления оповещений Dependabot для репозитория и security-events: write позволяет действию обновить состояние оповещений сканирования кода. Дополнительные сведения см. в разделе "Разрешения репозитория для оповещений проверки кода" и "Разрешения репозитория для оповещений Dependabot" в разделе "Разрешения, необходимые для приложений GitHub". |
statuses | Работа с состояниями фиксации. Например, statuses:read позволяет действию выводить список состояний фиксации для указанной ссылки. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
Определение доступа для GITHUB_TOKEN
областей
Вы можете определить доступ, который GITHUB_TOKEN
будет разрешен, указав read
или write``none
как значение доступных разрешений в permissions
ключе.
permissions:
actions: read|write|none
checks: read|write|none
contents: read|write|none
deployments: read|write|none
issues: read|write|none
discussions: read|write|none
packages: read|write|none
pages: read|write|none
pull-requests: read|write|none
repository-projects: read|write|none
security-events: read|write|none
statuses: read|write|none
Если указать доступ для любого из этих разрешений, то для всех этих разрешений задано none
значение .
Для определения одного из read-all
write-all
доступных разрешений можно использовать следующий синтаксис:
permissions: read-all
permissions: write-all
Для отключения разрешений для всех доступных разрешений можно использовать следующий синтаксис:
permissions: {}
Изменение разрешений в вилку репозитория
С помощью ключа permissions
можно добавлять и удалять разрешения на чтение для разветвленных репозиториев, но обычно предоставить доступ на запись нельзя. Исключением из этого поведения является то, что пользователь администратора выбрал Отправлять маркеры записи в рабочие процессы из запросов на вытягивание в параметрах GitHub Actions. Дополнительные сведения см. в разделе Управление параметрами GitHub Actions для репозитория.
GITHUB_TOKEN
Настройка разрешений для всех заданий в рабочем процессе
Можно указать permissions
на верхнем уровне рабочего процесса, чтобы параметр применялось ко всем заданиям в рабочем процессе.
Пример. Настройка GITHUB_TOKEN
разрешений для всего рабочего процесса
В этом примере показаны разрешения, заданные для GITHUB_TOKEN
, которые будут применены ко всем заданиям в рабочем процессе. Всем разрешениям предоставляется доступ на чтение.
name: "My workflow"
on: [ push ]
permissions: read-all
jobs:
...
env
Переменные map
, доступные для шагов всех заданий в рабочем процессе. Можно также задать переменные, доступные только для шагов одного задания или на одном шаге. Дополнительные сведения см. в разделах jobs.<job_id>.env
и jobs.<job_id>.steps[*].env
.
Переменные на схеме env
не могут быть определены с точки зрения других переменных на карте.
При определении нескольких переменных среды с тем же именем GitHub использует самую конкретную переменную. Например, переменная среды, определенная на шаге, переопределяет переменные задания и среды рабочего процесса с тем же именем, а шаг выполняется. Переменная среды, определенная для задания, переопределяет переменную рабочего процесса с тем же именем, а задание выполняется.
Пример env
env:
SERVER: production
defaults
Используйте defaults
для создания map
с параметрами по умолчанию, которые будут применяться ко всем заданиям в рабочем процессе. Можно также указать параметры по умолчанию, доступные только для задания. Дополнительные сведения см. в разделе jobs.<job_id>.defaults
.
Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.
defaults.run
Можно использовать defaults.run
для указания параметров по умолчанию shell
и working-directory
для всех этапов run
в рабочем процессе. Можно также указать параметры по умолчанию для run
, доступные только для задания. Дополнительные сведения см. в разделе jobs.<job_id>.defaults.run
. В этом ключевом слове нельзя использовать контексты или выражения.
Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.
Пример. Указание оболочки по умолчанию и рабочего каталога
defaults:
run:
shell: bash
working-directory: ./scripts
defaults.run.shell
Используется shell
для определения shell
шага. Этот ключевое слово может ссылаться на несколько контекстов. Дополнительные сведения см. в статье Контексты.
Поддерживаемая платформа | shell параметр | Description | Выполнение команды внутри системы |
---|---|---|---|
Linux / macOS | unspecified | Оболочка по умолчанию на платформах, отличных от Windows. Обратите внимание, что при этом выполняется другая команда, чем когда указать bash явно. Если bash не удается найти в пути, выполняется обработка в качестве sh . | bash -e {0} |
Все | bash | Оболочка по умолчанию на платформах, отличных от Windows, с резервным вариантом sh . При указании оболочки Bash на Windows используется оболочка Bash, включенная в Git для Windows. | bash --noprofile --norc -eo pipefail {0} |
Все | pwsh | PowerShell Core. GitHub добавляет расширение .ps1 к имени скрипта. | pwsh -command ". '{0}'" |
Все | python | Выполняет команду Python. | python {0} |
Linux / macOS | sh | Резервное поведение для платформ, отличных от Windows, если оболочка не указана и bash не найден в пути. | sh -e {0} |
Windows | cmd | GitHub добавляет расширение .cmd к имени скрипта и заменяет {0} . | %ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}"" . |
Windows | pwsh | Это оболочка по умолчанию, используемая в Windows. PowerShell Core. GitHub добавляет расширение .ps1 к имени скрипта. Если в локальном средстве выполнения Windows не установлен PowerShell Core, будет использоваться PowerShell Desktop. | pwsh -command ". '{0}'" . |
Windows | powershell | PowerShell Desktop. GitHub добавляет расширение .ps1 к имени скрипта. | powershell -command ". '{0}'" . |
Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.
defaults.run.working-directory
Используется working-directory
для определения рабочего каталога для shell
шага.
Tip
Перед запуском оболочки убедитесь, что working-directory
назначаемая функция существует в средстве выполнения.
Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.
concurrency
Используйте concurrency
, чтобы одновременно могли выполняться только одно задание или один процесс с использованием той же группы параллелизма. Группа параллелизма может представлять собой любую строку или выражение. Выражение может использовать [inputs``github
[](/actions/learn-github-actions/contexts#inputs-context) ](/actions/learn-github-actions/contexts#vars-context)vars
только контекст и контексты. Дополнительные сведения о выражениях см. в разделе "Оценка выражений в рабочих процессах и действиях".
Также можно задать concurrency
на уровне задания. Дополнительные сведения см. в разделе jobs.<job_id>.concurrency
.
Это означает, что в любое время в группе параллелизма может быть не более одного запущенного и одного ожидающего задания. Если параллельное задание или рабочий процесс добавлены в очередь и выполняется другое задание или рабочий процесс, использующие ту же группу параллелизма в репозитории, то находящиеся в очереди задание или рабочий процесс будут pending
. Любое существующее pending
задание или рабочий процесс в той же группе параллелизма, если она существует, будет отменена, а новое задание или рабочий процесс в очереди будет выполняться.
Чтобы также отменить задание или рабочий процесс, которые сейчас выполняются в той же группе параллелизма, укажите cancel-in-progress: true
. Чтобы условно отменить выполняемые в настоящее время задания или рабочие процессы в той же группе параллелизма, можно указать cancel-in-progress
как выражение с любым из контекстов разрешенного выражения.
Note
- Имя группы параллелизма не учитывает регистр. Например,
prod
иProd
будет рассматриваться как та же группа параллелизма. - Порядок не гарантируется для заданий или рабочих процессов с помощью групп параллелизма. Задания или рабочие процессы выполняются в одной группе параллелизма в произвольном порядке.
Пример. Использование параллелизма и поведения по умолчанию
Поведение по умолчанию GitHub Actions позволяет одновременно выполнять несколько заданий или рабочих процессов. Ключевое concurrency
слово позволяет управлять параллелизмом выполнения рабочих процессов.
Например, ключевое concurrency
слово можно использовать сразу после определения условий триггера, чтобы ограничить параллелизм всего рабочего процесса для определенной ветви:
on:
push:
branches:
- main
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
Кроме того, можно ограничить параллелизм заданий в рабочем процессе с помощью concurrency
ключевого слова на уровне задания:
on:
push:
branches:
- main
jobs:
job-1:
runs-on: ubuntu-latest
concurrency:
group: example-group
cancel-in-progress: true
Пример: группы параллелизма
Группы параллелизма предоставляют способ управления выполнением и ограничением выполнения выполнения рабочих процессов или заданий, использующих один и тот же ключ параллелизма.
Ключ concurrency
используется для группировки рабочих процессов или заданий в группу параллелизма. При определении concurrency
ключа GitHub Actions гарантирует, что в любое время выполняется только один рабочий процесс или задание с этим ключом. Если запуск или задание нового рабочего процесса начинается с того же concurrency
ключа, GitHub Actions отменит любой рабочий процесс или задание, уже запущенное с этим ключом. Ключ concurrency
может быть жестко закодированной строкой или может быть динамическим выражением, которое включает в себя переменные контекста.
Можно определить условия параллелизма в рабочем процессе, чтобы рабочий процесс или задание были частью группы параллелизма.
Это означает, что при запуске или запуске рабочего процесса GitHub отменяет все запуски рабочих процессов или задания, которые уже выполняются в той же группе параллелизма. Это полезно в сценариях, в которых требуется предотвратить параллельные запуски для определенного набора рабочих процессов или заданий, таких как те, которые используются для развертываний в промежуточной среде, чтобы предотвратить действия, которые могут вызвать конфликты или использовать больше ресурсов, чем необходимо.
В этом примере job-1
является частью группы параллелизма с именем staging_environment
. Это означает, что если запускается новый запуск job-1
, все запуски того же задания в staging_environment
группе параллелизма, которые уже выполняются, будут отменены.
jobs:
job-1:
runs-on: ubuntu-latest
concurrency:
group: staging_environment
cancel-in-progress: true
Кроме того, использование динамического выражения, например concurrency: ci-${{ github.ref }}
в рабочем процессе, означает, что рабочий процесс или задание будет частью группы ci-
параллелизма, за которой следует ссылка на ветвь или тег, активировавший рабочий процесс. В этом примере, если новая фиксация отправляется в основную ветвь, пока предыдущий запуск по-прежнему выполняется, предыдущий запуск будет отменен, а новый будет запущен:
on:
push:
branches:
- main
concurrency:
group: ci-${{ github.ref }}
cancel-in-progress: true
Пример. Использование параллелизма для отмены любого выполняющегося задания или запуска
Чтобы использовать параллелизм для отмены любого выполняемого задания или запуска в GitHub Actions, можно использовать concurrency
ключ с параметром cancel-in-progress
:true
concurrency:
group: ${{ github.ref }}
cancel-in-progress: true
Обратите внимание, что в этом примере без определения определенной группы параллелизма GitHub Actions отменит выполнение задания или рабочего процесса.
Пример. Использование резервного значения
Если вы создаете имя группы со свойством, определенным только для определенных событий, можно использовать резервное значение. Например, github.head_ref
определяется только для событий pull_request
. Если рабочий процесс реагирует на другие события в дополнение к событиям pull_request
, необходимо предоставить резервное значение, чтобы избежать синтаксической ошибки. Следующая группа параллелизма отменяет выполняемые задания или запуски только в событиях pull_request
. Если параметр github.head_ref
не определен, группа параллелизма перейдет к идентификатору запуска, который будет гарантированно заданным и уникальным.
concurrency:
group: ${{ github.head_ref || github.run_id }}
cancel-in-progress: true
Пример. Отмена только выполняемых заданий или запусков для текущего рабочего процесса
При наличии нескольких рабочих процессов в одном репозитории имена групп параллелизма должны быть уникальными в разных рабочих процессах, чтобы избежать отмены выполняемых заданий или запусков из других рабочих процессов. В противном случае все ранее выполняемые или ожидающие задания будут отменены независимо от рабочего процесса.
Чтобы отменить только выполняемые запуски для одного рабочего процесса, можно использовать свойство github.workflow
для создания группы параллелизма:
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
Пример. Отмена только выполняемых заданий в определенных ветвях
Если вы хотите отменить выполняемые задания в определенных ветвях, но не на других, можно использовать условные выражения с cancel-in-progress
. Например, это можно сделать, если вы хотите отменить выполняемые задания в ветвях разработки, но не в ветвях выпуска.
Чтобы отменить выполнение только выполняемых запусков одного рабочего процесса, если он не запущен в ветви выпуска, можно задать cancel-in-progress
выражение, аналогичное следующему:
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: ${{ !contains(github.ref, 'release/')}}
В этом примере несколько push-уведомлений в release/1.2.3
ветвь не отменяют выполняемые запуски. Отправка в другую ветвь, например main
, отменяет выполняемые запуски.
jobs
Запуск рабочего процесса состоит из одного или нескольких jobs
, которые по умолчанию выполняются параллельно. Для последовательного выполнения заданий можно определить зависимости в других заданиях с помощью ключевого слова jobs.<job_id>.needs
.
Каждое задание выполняется в среде средства выполнения тестов, указанной в параметре runs-on
.
Вы можете выполнять неограниченное количество заданий, если вы не превышаете лимиты по использованию рабочих процессов. Дополнительные сведения см. в разделе "[AUTOTITLE" для GitHubразмещенных в среде runner и autoTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#usage-limits) для ограничения использования локального runner.
Если требуется найти уникальный идентификатор задания, выполняемого в ходе выполнения рабочего процесса, можно использовать API GitHub Enterprise Server. Дополнительные сведения см. в разделе Конечные точки REST API для действий GitHub.
jobs.<job_id>
Используйте jobs.<job_id>
, чтобы назначить заданию уникальный идентификатор. Ключ job_id
представляет собой строку, а значение ключа представляет собой карту данных конфигурации задания. Необходимо заменить <job_id>
строкой, уникальной для объекта jobs
. <job_id>
должен начинаться с буквы или _
и может включать только буквенно-цифровые символы -
или _
.
Пример. Создание заданий
В этом примере были созданы два задания, и их job_id
равны my_first_job
и my_second_job
.
jobs:
my_first_job:
name: My first job
my_second_job:
name: My second job
jobs.<job_id>.name
Используйте jobs.<job_id>.name
для присвоения имени заданию, которое отображается в пользовательском интерфейсе GitHub.
jobs.<job_id>.permissions
Для определенного задания jobs.<job_id>.permissions
можно использовать для изменения разрешений по умолчанию, предоставленных GITHUB_TOKEN
, при необходимости добавляя или удаляя права доступа, чтобы разрешить только минимальный требуемый доступ. Дополнительные сведения см. в разделе Автоматическая проверка подлинности токенов.
Указав разрешение в определении задания, при необходимости можно настроить для каждого задания другой набор разрешений для GITHUB_TOKEN
. Кроме того, можно указать разрешения для всех заданий в рабочем процессе. Сведения об определении разрешений на уровне рабочего процесса см. в разделе permissions
.
Для каждого из доступных разрешений, показанных в таблице ниже, можно назначить один из уровней доступа: read
(если применимо), write
или none
. write
включает в себя read
. Если указать доступ для любого из этих разрешений, то для всех этих разрешений задано none
значение .
Доступные разрешения и подробные сведения о том, что позволяет выполнять действие:
Разрешение | Разрешает действие с помощью GITHUB_TOKEN |
---|---|
actions | Работа с GitHub Actions. Например, actions: write позволяет действию отменить выполнение рабочего процесса. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
checks | Работа с проверками запусков и контрольных наборов. Например, checks: write позволяет действию создать выполнение проверки. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
contents | Работа с содержимым репозитория. Например, contents: read позволяет действию перечислять фиксации и contents: write позволяет действию создавать выпуск. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
deployments | Работа с развертываниями. Например, deployments: write позволяет действию создать новое развертывание. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
discussions | Работа с обсуждениями GitHub. Например, discussions: write позволяет действию закрыть или удалить обсуждение. Дополнительные сведения см. в разделе «Использование API GraphQL для обсуждений». |
issues | Работа с проблемами. Например, issues: write позволяет действию добавить комментарий к проблеме. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
packages | Работа с пакетами GitHub. Например, packages: write позволяет действию отправлять и публиковать пакеты в пакетах GitHub. Дополнительные сведения см. в разделе «Сведения о разрешениях для пакетов GitHub». |
pages | Работа с GitHub Pages. Например, pages: write позволяет действию запрашивать сборку GitHub Pages. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
pull-requests | Работа с запросами на вытягивание. Например, pull-requests: write позволяет действию добавить метку в запрос на вытягивание. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
repository-projects | Работа с проектами GitHub (классическая модель). Например, repository-projects: write позволяет действию добавить столбец в проект (классическую модель). Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
security-events | Работа с проверкой кода GitHub и оповещениями Dependabot. Например, security-events: read позволяет выполнить действие для перечисления оповещений Dependabot для репозитория и security-events: write позволяет действию обновить состояние оповещений сканирования кода. Дополнительные сведения см. в разделе "Разрешения репозитория для оповещений проверки кода" и "Разрешения репозитория для оповещений Dependabot" в разделе "Разрешения, необходимые для приложений GitHub". |
statuses | Работа с состояниями фиксации. Например, statuses:read позволяет действию выводить список состояний фиксации для указанной ссылки. Дополнительные сведения см. в разделе «Разрешения, необходимые для приложений GitHub». |
Определение доступа для GITHUB_TOKEN
областей
Вы можете определить доступ, который GITHUB_TOKEN
будет разрешен, указав read
или write``none
как значение доступных разрешений в permissions
ключе.
permissions:
actions: read|write|none
checks: read|write|none
contents: read|write|none
deployments: read|write|none
issues: read|write|none
discussions: read|write|none
packages: read|write|none
pages: read|write|none
pull-requests: read|write|none
repository-projects: read|write|none
security-events: read|write|none
statuses: read|write|none
Если указать доступ для любого из этих разрешений, то для всех этих разрешений задано none
значение .
Для определения одного из read-all
write-all
доступных разрешений можно использовать следующий синтаксис:
permissions: read-all
permissions: write-all
Для отключения разрешений для всех доступных разрешений можно использовать следующий синтаксис:
permissions: {}
Изменение разрешений в вилку репозитория
С помощью ключа permissions
можно добавлять и удалять разрешения на чтение для разветвленных репозиториев, но обычно предоставить доступ на запись нельзя. Исключением из этого поведения является то, что пользователь администратора выбрал Отправлять маркеры записи в рабочие процессы из запросов на вытягивание в параметрах GitHub Actions. Дополнительные сведения см. в разделе Управление параметрами GitHub Actions для репозитория.
Пример. Настройка GITHUB_TOKEN
разрешений для одного задания в рабочем процессе
В этом примере показаны разрешения, заданные для задания GITHUB_TOKEN
, которое будет применяться только к заданию с именем stale
. Доступ на запись предоставляется для issues
разрешений и pull-requests
разрешений. Все остальные разрешения не будут иметь доступа.
jobs:
stale:
runs-on: ubuntu-latest
permissions:
issues: write
pull-requests: write
steps:
- uses: actions/stale@v5
jobs.<job_id>.needs
Используйте jobs.<job_id>.needs
для определения всех заданий, которые должны быть успешно завершены перед выполнением этого задания. Это может быть строка или массив строк. Если задание завершается ошибкой или пропускается, все задания, необходимые для него, пропускаются, если задания не используют условное выражение, которое приводит к продолжению задания. Если выполнение содержит ряд заданий, которые нуждаются друг в другом, сбой или пропуск применяется ко всем заданиям в цепочке зависимостей из точки сбоя или пропускания. Если вы хотите выполнить задание, даже если задание зависит от не удалось, используйте условное always()
выражение в jobs.<job_id>.if
.
Пример. Необходимо успешное выполнение зависимых заданий
jobs:
job1:
job2:
needs: job1
job3:
needs: [job1, job2]
В этом примере задание job1
должно успешно завершить работу перед началом задания job2
, а задание job3
ожидает завершения заданий job1
и job2
.
Задания в этом примере выполняются последовательно:
job1
job2
job3
Пример. Успешное выполнение зависимых заданий не требуется
jobs:
job1:
job2:
needs: job1
job3:
if: ${{ always() }}
needs: [job1, job2]
В этом примере в задании job3
используется условное выражение always()
, чтобы оно всегда выполнялось после завершения выполнения заданий job1
и job2
, независимо от того, завершились ли они успешно. Дополнительные сведения см. в разделе Оценка выражений в рабочих процессах и действиях.
jobs.<job_id>.if
Условное выражение jobs.<job_id>.if
можно использовать для предотвращения выполнения задания, если условие не выполняется. Для создания условного выражения можно использовать любой поддерживаемый контекст и любое выражение. Дополнительные сведения о том, какие контексты поддерживаются в этом ключе, см. в разделе "Доступ к контекстной информации о запусках рабочих процессов".
Note
Условие jobs.<job_id>.if
вычисляется перед jobs.<job_id>.strategy.matrix
применением.
При использовании выражений в условном if
режиме можно, при необходимости, опустить синтаксис выражения ${{ }}
, так как GitHub Actions автоматически вычисляет условное if
выражение как выражение. Однако это исключение не применяется везде.
Всегда следует использовать синтаксис выражения ${{ }}
{% концевого выражения %} или экранировать с ''
, ""
либо ()
когда выражение начинается с !
, так как !
зарезервировано нотация в формате YAML. Например:
{% raw %}
if: ${{ ! startsWith(github.ref, 'refs/tags/') }}
Дополнительные сведения см. в разделе "Оценка выражений в рабочих процессах и действиях".
Пример. Выполнение задания только для определенного репозитория
В этом примере используется if
для управления выполнением задания production-deploy
. Оно будет выполняться только в том случае, если репозиторий имеет имя octo-repo-prod
и находится в организации octo-org
. В противном случае задание будет отмечено как пропущенное.
name: example-workflow on: [push] jobs: production-deploy: if: github.repository == 'octo-org/octo-repo-prod' runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '14' - run: npm install -g bats
name: example-workflow
on: [push]
jobs:
production-deploy:
if: github.repository == 'octo-org/octo-repo-prod'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '14'
- run: npm install -g bats
jobs.<job_id>.runs-on
Выбор средства выполнения тестов, размещенного на GitHub
Выбор локальных средств выполнения тестов
Выбор бегуна в группе
jobs.<job_id>.environment
Используется jobs.<job_id>.environment
для определения среды, на которую ссылается задание.
Вы можете указать среду в виде только имени среды name
или в виде объекта среды с name
и url
. URL-адрес сопоставляется с environment_url
в API развертываний. Дополнительные сведения об API развертываний см. в разделе "Конечные точки REST API для репозиториев".
Note
Все правила защиты развертывания должны передаваться перед отправкой задания, ссылающегося на среду, в средство выполнения. Дополнительные сведения см. в разделе «Управление средами для развертывания».
Пример. Использование только имени среды
environment: staging_environment
Пример. Использование имени среды и URL-адреса
environment:
name: production_environment
url: https://github.com
Значение url
может быть выражением. Контексты разрешенных выражений: github
, [[matrix
[[strategy
env
](/actions/learn-github-actions/contexts#env-context)runner``inputs
vars``needs
](/actions/learn-github-actions/contexts#vars-context)[](/actions/learn-github-actions/contexts#runner-context)](/actions/learn-github-actions/contexts#matrix-context)job
](/actions/learn-github-actions/contexts#needs-context)и .steps
Дополнительные сведения о выражениях см. в разделе "Оценка выражений в рабочих процессах и действиях".
Пример. Использование выходных данных в качестве URL-адреса
environment:
name: production_environment
url: ${{ steps.step_id.outputs.url_output }}
Значение name
может быть выражением. Контексты разрешенных выражений: github
,inputs
, vars
,needs
,strategy
и .matrix
Дополнительные сведения о выражениях см. в разделе "Оценка выражений в рабочих процессах и действиях".
Пример. Использование выражения в качестве имени среды
environment:
name: ${{ github.ref_name }}
jobs.<job_id>.concurrency
Можно использовать jobs.<job_id>.concurrency
, чтобы одновременно могли выполняться только одно задание или один процесс с использованием той же группы параллелизма. Группа параллелизма может представлять собой любую строку или выражение. Контексты разрешенных выражений: github
,inputs
, vars
,needs
,strategy
и .matrix
Дополнительные сведения о выражениях см. в разделе "Оценка выражений в рабочих процессах и действиях".
Можно также указать concurrency
на уровне рабочего процесса. Дополнительные сведения см. в разделе concurrency
.
Это означает, что в любое время в группе параллелизма может быть не более одного запущенного и одного ожидающего задания. Если параллельное задание или рабочий процесс добавлены в очередь и выполняется другое задание или рабочий процесс, использующие ту же группу параллелизма в репозитории, то находящиеся в очереди задание или рабочий процесс будут pending
. Любое существующее pending
задание или рабочий процесс в той же группе параллелизма, если она существует, будет отменена, а новое задание или рабочий процесс в очереди будет выполняться.
Чтобы также отменить задание или рабочий процесс, которые сейчас выполняются в той же группе параллелизма, укажите cancel-in-progress: true
. Чтобы условно отменить выполняемые в настоящее время задания или рабочие процессы в той же группе параллелизма, можно указать cancel-in-progress
как выражение с любым из контекстов разрешенного выражения.
Note
- Имя группы параллелизма не учитывает регистр. Например,
prod
иProd
будет рассматриваться как та же группа параллелизма. - Порядок не гарантируется для заданий или рабочих процессов с помощью групп параллелизма. Задания или рабочие процессы выполняются в одной группе параллелизма в произвольном порядке.
Пример. Использование параллелизма и поведения по умолчанию
Поведение по умолчанию GitHub Actions позволяет одновременно выполнять несколько заданий или рабочих процессов. Ключевое concurrency
слово позволяет управлять параллелизмом выполнения рабочих процессов.
Например, ключевое concurrency
слово можно использовать сразу после определения условий триггера, чтобы ограничить параллелизм всего рабочего процесса для определенной ветви:
on:
push:
branches:
- main
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
Кроме того, можно ограничить параллелизм заданий в рабочем процессе с помощью concurrency
ключевого слова на уровне задания:
on:
push:
branches:
- main
jobs:
job-1:
runs-on: ubuntu-latest
concurrency:
group: example-group
cancel-in-progress: true
Пример: группы параллелизма
Группы параллелизма предоставляют способ управления выполнением и ограничением выполнения выполнения рабочих процессов или заданий, использующих один и тот же ключ параллелизма.
Ключ concurrency
используется для группировки рабочих процессов или заданий в группу параллелизма. При определении concurrency
ключа GitHub Actions гарантирует, что в любое время выполняется только один рабочий процесс или задание с этим ключом. Если запуск или задание нового рабочего процесса начинается с того же concurrency
ключа, GitHub Actions отменит любой рабочий процесс или задание, уже запущенное с этим ключом. Ключ concurrency
может быть жестко закодированной строкой или может быть динамическим выражением, которое включает в себя переменные контекста.
Можно определить условия параллелизма в рабочем процессе, чтобы рабочий процесс или задание были частью группы параллелизма.
Это означает, что при запуске или запуске рабочего процесса GitHub отменяет все запуски рабочих процессов или задания, которые уже выполняются в той же группе параллелизма. Это полезно в сценариях, в которых требуется предотвратить параллельные запуски для определенного набора рабочих процессов или заданий, таких как те, которые используются для развертываний в промежуточной среде, чтобы предотвратить действия, которые могут вызвать конфликты или использовать больше ресурсов, чем необходимо.
В этом примере job-1
является частью группы параллелизма с именем staging_environment
. Это означает, что если запускается новый запуск job-1
, все запуски того же задания в staging_environment
группе параллелизма, которые уже выполняются, будут отменены.
jobs:
job-1:
runs-on: ubuntu-latest
concurrency:
group: staging_environment
cancel-in-progress: true
Кроме того, использование динамического выражения, например concurrency: ci-${{ github.ref }}
в рабочем процессе, означает, что рабочий процесс или задание будет частью группы ci-
параллелизма, за которой следует ссылка на ветвь или тег, активировавший рабочий процесс. В этом примере, если новая фиксация отправляется в основную ветвь, пока предыдущий запуск по-прежнему выполняется, предыдущий запуск будет отменен, а новый будет запущен:
on:
push:
branches:
- main
concurrency:
group: ci-${{ github.ref }}
cancel-in-progress: true
Пример. Использование параллелизма для отмены любого выполняющегося задания или запуска
Чтобы использовать параллелизм для отмены любого выполняемого задания или запуска в GitHub Actions, можно использовать concurrency
ключ с параметром cancel-in-progress
:true
concurrency:
group: ${{ github.ref }}
cancel-in-progress: true
Обратите внимание, что в этом примере без определения определенной группы параллелизма GitHub Actions отменит выполнение задания или рабочего процесса.
Пример. Использование резервного значения
Если вы создаете имя группы со свойством, определенным только для определенных событий, можно использовать резервное значение. Например, github.head_ref
определяется только для событий pull_request
. Если рабочий процесс реагирует на другие события в дополнение к событиям pull_request
, необходимо предоставить резервное значение, чтобы избежать синтаксической ошибки. Следующая группа параллелизма отменяет выполняемые задания или запуски только в событиях pull_request
. Если параметр github.head_ref
не определен, группа параллелизма перейдет к идентификатору запуска, который будет гарантированно заданным и уникальным.
concurrency:
group: ${{ github.head_ref || github.run_id }}
cancel-in-progress: true
Пример. Отмена только выполняемых заданий или запусков для текущего рабочего процесса
При наличии нескольких рабочих процессов в одном репозитории имена групп параллелизма должны быть уникальными в разных рабочих процессах, чтобы избежать отмены выполняемых заданий или запусков из других рабочих процессов. В противном случае все ранее выполняемые или ожидающие задания будут отменены независимо от рабочего процесса.
Чтобы отменить только выполняемые запуски для одного рабочего процесса, можно использовать свойство github.workflow
для создания группы параллелизма:
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
Пример. Отмена только выполняемых заданий в определенных ветвях
Если вы хотите отменить выполняемые задания в определенных ветвях, но не на других, можно использовать условные выражения с cancel-in-progress
. Например, это можно сделать, если вы хотите отменить выполняемые задания в ветвях разработки, но не в ветвях выпуска.
Чтобы отменить выполнение только выполняемых запусков одного рабочего процесса, если он не запущен в ветви выпуска, можно задать cancel-in-progress
выражение, аналогичное следующему:
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: ${{ !contains(github.ref, 'release/')}}
В этом примере несколько push-уведомлений в release/1.2.3
ветвь не отменяют выполняемые запуски. Отправка в другую ветвь, например main
, отменяет выполняемые запуски.
jobs.<job_id>.outputs
Можно использовать jobs.<job_id>.outputs
для создания map
выходных данных для задания. Выходные данные задания доступны для всех подчиненных заданий, которые зависят от этого задания. Дополнительные сведения об определении зависимостей заданий см. в разделе jobs.<job_id>.needs
.
Выходные данные представляют собой строки Юникода длиной не более 1 МБ. Общий объем выходных данных в выполнении рабочего процесса не может превышать 50 МБ.
Выходные данные задания, содержащие выражения, вычисляются в средстве выполнения в конце каждого задания. Выходные данные, содержащие секреты, редактируются в средстве выполнения и не отправляются в GitHub Actions.
Если выходные данные пропущены, так как он может содержать секрет, появится следующее предупреждение: "Пропустить выходные данные {output.Key}
, так как он может содержать секрет". Дополнительные сведения об обработке секретов см. в примере: маскирование и передача секрета между заданиями или рабочими процессами.
Чтобы применять выходные данные задания в зависимом задании, можно использовать контекст needs
. Дополнительные сведения см. в разделе «Доступ к контекстной информации о запусках рабочих процессов».
Пример: определение выходных данных для задания
jobs:
job1:
runs-on: ubuntu-latest
# Map a step output to a job output
outputs:
output1: ${{ steps.step1.outputs.test }}
output2: ${{ steps.step2.outputs.test }}
steps:
- id: step1
run: echo "test=hello" >> "$GITHUB_OUTPUT"
- id: step2
run: echo "test=world" >> "$GITHUB_OUTPUT"
job2:
runs-on: ubuntu-latest
needs: job1
steps:
- env:
OUTPUT1: ${{needs.job1.outputs.output1}}
OUTPUT2: ${{needs.job1.outputs.output2}}
run: echo "$OUTPUT1 $OUTPUT2"
Использование выходных данных задания в матрицном задании
Матрицы можно использовать для создания нескольких выходных данных разных имен. При использовании матрицы выходные данные заданий будут объединены из всех заданий внутри матрицы.
jobs:
job1:
runs-on: ubuntu-latest
outputs:
output_1: ${{ steps.gen_output.outputs.output_1 }}
output_2: ${{ steps.gen_output.outputs.output_2 }}
output_3: ${{ steps.gen_output.outputs.output_3 }}
strategy:
matrix:
version: [1, 2, 3]
steps:
- name: Generate output
id: gen_output
run: |
version="${{ matrix.version }}"
echo "output_${version}=${version}" >> "$GITHUB_OUTPUT"
job2:
runs-on: ubuntu-latest
needs: [job1]
steps:
# Will show
# {
# "output_1": "1",
# "output_2": "2",
# "output_3": "3"
# }
- run: echo '${{ toJSON(needs.job1.outputs) }}'
Warning
Действия не гарантируют порядок выполнения заданий матрицы. Убедитесь, что выходное имя уникально, в противном случае последнее задание матрицы, которое выполняется, переопределит выходное значение.
jobs.<job_id>.env
Переменные map
, доступные для всех шагов в задании. Можно задать переменные для всего рабочего процесса или отдельного шага. Дополнительные сведения см. в разделах env
и jobs.<job_id>.steps[*].env
.
При определении нескольких переменных среды с тем же именем GitHub использует самую конкретную переменную. Например, переменная среды, определенная на шаге, переопределяет переменные задания и среды рабочего процесса с тем же именем, а шаг выполняется. Переменная среды, определенная для задания, переопределяет переменную рабочего процесса с тем же именем, а задание выполняется.
Пример jobs.<job_id>.env
jobs:
job1:
env:
FIRST_NAME: Mona
jobs.<job_id>.defaults
Используйте jobs.<job_id>.defaults
для создания map
с параметрами по умолчанию, которые будут применяться ко всем шагам задания. Вы также можете задать параметры по умолчанию для всего рабочего процесса. Дополнительные сведения см. в разделе defaults
.
Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.
jobs.<job_id>.defaults.run
Использует jobs.<job_id>.defaults.run
для предоставления параметры по умолчанию shell
и working-directory
для всех этапов run
в задании.
Можно указать параметры по умолчанию shell
и working-directory
для всех этапов run
в задании. Вы также можете задать параметры по умолчанию для run
для всего рабочего процесса. Дополнительные сведения см. в разделе defaults.run
.
Их можно переопределить на jobs.<job_id>.defaults.run
уровнях и jobs.<job_id>.steps[*].run
уровнях.
Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.
jobs.<job_id>.defaults.run.shell
Используется shell
для определения shell
шага. Этот ключевое слово может ссылаться на несколько контекстов. Дополнительные сведения см. в статье Контексты.
Поддерживаемая платформа | shell параметр | Description | Выполнение команды внутри системы |
---|---|---|---|
Linux / macOS | unspecified | Оболочка по умолчанию на платформах, отличных от Windows. Обратите внимание, что при этом выполняется другая команда, чем когда указать bash явно. Если bash не удается найти в пути, выполняется обработка в качестве sh . | bash -e {0} |
Все | bash | Оболочка по умолчанию на платформах, отличных от Windows, с резервным вариантом sh . При указании оболочки Bash на Windows используется оболочка Bash, включенная в Git для Windows. | bash --noprofile --norc -eo pipefail {0} |
Все | pwsh | PowerShell Core. GitHub добавляет расширение .ps1 к имени скрипта. | pwsh -command ". '{0}'" |
Все | python | Выполняет команду Python. | python {0} |
Linux / macOS | sh | Резервное поведение для платформ, отличных от Windows, если оболочка не указана и bash не найден в пути. | sh -e {0} |
Windows | cmd | GitHub добавляет расширение .cmd к имени скрипта и заменяет {0} . | %ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}"" . |
Windows | pwsh | Это оболочка по умолчанию, используемая в Windows. PowerShell Core. GitHub добавляет расширение .ps1 к имени скрипта. Если в локальном средстве выполнения Windows не установлен PowerShell Core, будет использоваться PowerShell Desktop. | pwsh -command ". '{0}'" . |
Windows | powershell | PowerShell Desktop. GitHub добавляет расширение .ps1 к имени скрипта. | powershell -command ". '{0}'" . |
Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.
jobs.<job_id>.defaults.run.working-directory
Используется working-directory
для определения рабочего каталога для shell
шага.
Tip
Перед запуском оболочки убедитесь, что working-directory
назначаемая функция существует в средстве выполнения.
Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.
Пример. Настройка параметров этапа по умолчанию run
для задания
jobs:
job1:
runs-on: ubuntu-latest
defaults:
run:
shell: bash
working-directory: ./scripts
jobs.<job_id>.steps
Задание содержит последовательность задач, называемых шагами (steps
). Шаги могут выполнять команды, задачи установки или действия в репозитории, общедоступном репозитории или в реестре Docker. Не все шаги выполняют действия, но все действия выполняются как шаги. Каждый шаг выполняется в собственном процессе в среде средства выполнения и имеет доступ к рабочей области и файловой системе. Так как шаги выполняются в собственном процессе, изменения переменных среды не сохраняются между шагами. GitHub предоставляет встроенные шаги по настройке и выполнению задания.
GitHub отображает только первые 1000 проверок, однако вы можете выполнять неограниченное количество шагов, если вы находитесь в пределах ограничений использования рабочего процесса. Дополнительные сведения см. в разделе [AUTOTITLE для GitHubразмещенных в среде runner и Ограничения использования, выставление счетов и администрирование](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#usage-limits) для ограничения использования локального runner.
Пример jobs.<job_id>.steps
name: Greeting from Mona
on: push
jobs:
my-job:
name: My Job
runs-on: ubuntu-latest
steps:
- name: Print a greeting
env:
MY_VAR: Hi there! My name is
FIRST_NAME: Mona
MIDDLE_NAME: The
LAST_NAME: Octocat
run: |
echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.
jobs.<job_id>.steps[*].id
Уникальный идентификатор шага. Вы можете использовать id
для ссылки на шаг в контекстах. Дополнительные сведения см. в разделе Доступ к контекстной информации о запусках рабочих процессов.
jobs.<job_id>.steps[*].if
Условное выражение if
можно использовать для предотвращения выполнения шага, если условие не выполняется. Для создания условного выражения можно использовать любой поддерживаемый контекст и любое выражение. Дополнительные сведения о том, какие контексты поддерживаются в этом ключе, см. в разделе "Доступ к контекстной информации о запусках рабочих процессов".
При использовании выражений в условном if
режиме можно, при необходимости, опустить синтаксис выражения ${{ }}
, так как GitHub Actions автоматически вычисляет условное if
выражение как выражение. Однако это исключение не применяется везде.
Всегда следует использовать синтаксис выражения ${{ }}
{% концевого выражения %} или экранировать с ''
, ""
либо ()
когда выражение начинается с !
, так как !
зарезервировано нотация в формате YAML. Например:
{% raw %}
if: ${{ ! startsWith(github.ref, 'refs/tags/') }}
Дополнительные сведения см. в разделе Оценка выражений в рабочих процессах и действиях.
Пример. Использование контекстов
Этот шаг выполняется, только если типом события является pull_request
, а действием — unassigned
.
steps:
- name: My first step
if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}
run: echo This event is a pull request that had an assignee removed.
Пример. Использование функций проверки состояния
my backup step
выполняется только при сбое предыдущего шага задания. Дополнительные сведения см. в разделе Оценка выражений в рабочих процессах и действиях.
steps:
- name: My first step
uses: octo-org/action-name@main
- name: My backup step
if: ${{ failure() }}
uses: actions/heroku@1.0.0
Пример. Использование секретов
На секреты нельзя напрямую ссылаться в условных выражениях if:
. Вместо этого рекомендуется задать секреты в качестве переменных среды на уровне задания, а затем создать ссылки на переменные среды для условного выполнения шагов в задании.
Если секрет не задан, возвращаемое значение выражения, которое ссылается на этот секрет (например, ${{ secrets.SuperSecret }}
в примере) будет пустой строкой.
name: Run a step if a secret has been set
on: push
jobs:
my-jobname:
runs-on: ubuntu-latest
env:
super_secret: ${{ secrets.SuperSecret }}
steps:
- if: ${{ env.super_secret != '' }}
run: echo 'This step will only run if the secret has a value set.'
- if: ${{ env.super_secret == '' }}
run: echo 'This step will only run if the secret does not have a value set.'
Дополнительные сведения см. в разделе [AUTOTITLE и Доступ к контекстной информации о запусках рабочих процессов](/actions/security-guides/using-secrets-in-github-actions).
jobs.<job_id>.steps[*].name
Имя шага, которое будет отображаться на GitHub.
jobs.<job_id>.steps[*].uses
Выбирает действие, которое будет выполняться как часть шага вашего задания. Действие — это многократно используемая единица кода. Вы можете использовать действие, определенное в том же репозитории, что и рабочий процесс, в общедоступном репозитории или в опубликованном образе контейнера Docker.
Мы настоятельно рекомендуем включить версию используемого вами действия, указав ссылку на Git, SHA или тег Docker. Если вы не укажете версию, это может нарушить ваши рабочие процессы или вызвать непредвиденное поведение, когда владелец действия будет публиковать обновление.
- Использование SHA фиксации выпущенной версии действия является самым безопасным для стабильности и защиты.
- Если действие публикует теги основного номера версий, вам следует ожидать получения критических исправлений и обновлений для системы безопасности. При этом совместимость сохранится. Обратите внимание, что это поведение выполняется по усмотрению автора действия.
- Использование ветви действия по умолчанию может быть удобным, но если кто-то выпустит новую основную версию с критическим изменением, ваш рабочий процесс может прерваться.
Для некоторых действий требуются входные данные, заданные с помощью ключевого слова with
. Просмотрите файл README действия, чтобы определить необходимые ввода.
Действия — это файлы JavaScript или контейнеры Docker. Если используемое действие является контейнером Docker, необходимо запустить задание в среде Linux. Дополнительные сведения см. в статье runs-on
.
Пример. Использование действий с версиями
steps:
# Reference a specific commit
- uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3
# Reference the major version of a release
- uses: actions/checkout@v4
# Reference a specific version
- uses: actions/checkout@v4.2.0
# Reference a branch
- uses: actions/checkout@main
Пример. Использование общедоступного действия
{owner}/{repo}@{ref}
Вы можете указать ветвь, ссылку или SHA в общедоступном репозитории данных GitHub.
jobs:
my_first_job:
steps:
- name: My first step
# Uses the default branch of a public repository
uses: actions/heroku@main
- name: My second step
# Uses a specific version tag of a public repository
uses: actions/aws@v2.0.1
Пример. Использование общедоступного действия в подкаталоге
{owner}/{repo}/{path}@{ref}
Подкаталог в общедоступном репозитории GitHub в определенной ветви, ссылке или SHA.
jobs:
my_first_job:
steps:
- name: My first step
uses: actions/aws/ec2@main
Пример. Использование действия в том же репозитории, что и рабочий процесс
./path/to/dir
Путь к каталогу, содержащему действие в репозитории рабочего процесса. Перед использованием действия необходимо извлечь репозиторий.
Пример. Использование действия Docker Hub
docker://{image}:{tag}
Образ Docker, опубликованный в Docker Hub.
jobs:
my_first_job:
steps:
- name: My first step
uses: docker://alpine:3.8
Пример. Использование действия общедоступного реестра Docker
docker://{host}/{image}:{tag}
Образ Docker в общедоступном реестре. В этом примере используется реестр контейнеров Google: gcr.io
.
jobs:
my_first_job:
steps:
- name: My first step
uses: docker://gcr.io/cloud-builders/gradle
Пример. Использование действия в частном репозитории, отличном от того, где выполняется рабочий процесс
Рабочий процесс должен извлечь частный репозиторий и ссылаться на действие локально. Создайте personal access token и добавьте маркер в качестве секрета. Дополнительные сведения см. в разделе [AUTOTITLE и Управление личными маркерами доступа](/actions/security-guides/using-secrets-in-github-actions).
Замените PERSONAL_ACCESS_TOKEN
в примере именем секрета.
jobs:
my_first_job:
steps:
- name: Check out repository
uses: actions/checkout@v4
with:
repository: octocat/my-private-repo
ref: v1.0
token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
path: ./.github/actions/my-private-repo
- name: Run my action
uses: ./.github/actions/my-private-repo/my-action
Кроме того, используйте GitHub App вместо personal access token для того, чтобы рабочий процесс продолжал работать, даже если владелец personal access token оставляет владельца. Дополнительные сведения см. в разделе Выполнение запросов API с проверкой подлинности с помощью приложения GitHub в рабочем процессе GitHub Actions.
jobs.<job_id>.steps[*].run
Запускает программы командной строки, не превышающие 21 000 символов с помощью оболочки операционной системы. Если name
не указано, в качестве имени шага по умолчанию используется текст, указанный в команде run
.
Команды выполняются с помощью оболочки, не требующей входа, по умолчанию. Вы можете выбрать другую оболочку и настроить ее для выполнения команд. Дополнительные сведения см. в разделе jobs.<job_id>.steps[*].shell
.
Каждое ключевое слово run
представляет новый процесс и оболочку в среде средства выполнения. При предоставлении команд с несколькими строками каждая строка выполняется в той же оболочке. Например:
-
Команда с одной строкой:
- name: Install Dependencies run: npm install
-
Команда с несколькими строками:
- name: Clean install dependencies and build run: | npm ci npm run build
jobs.<job_id>.steps[*].working-directory
С помощью ключевого слова working-directory
можно указать рабочий каталог, в котором будет выполняться команда.
- name: Clean temp directory
run: rm -rf *
working-directory: ./temp
Кроме того, можно указать рабочий каталог по умолчанию для всех run
шагов в задании или для всех run
шагов всего рабочего процесса. Дополнительные сведения см. в разделах defaults.run.working-directory
и jobs.<job_id>.defaults.run.working-directory
.
Вы также можете использовать run
шаг для запуска скрипта. Дополнительные сведения см. в разделе Добавление сценариев в рабочий процесс.
jobs.<job_id>.steps[*].shell
Параметры оболочки по умолчанию можно переопределить в операционной системе runner и по умолчанию задания с помощью ключевого shell
слова. Можно использовать встроенные ключевые слова shell
или определить пользовательский набор параметров оболочки. Команда оболочки, выполняемая внутри системы, исполняет временный файл, содержащий команды, указанные в ключевом слове run
.
Поддерживаемая платформа | shell параметр | Description | Выполнение команды внутри системы |
---|---|---|---|
Linux / macOS | unspecified | Оболочка по умолчанию на платформах, отличных от Windows. Обратите внимание, что при этом выполняется другая команда, чем когда указать bash явно. Если bash не удается найти в пути, выполняется обработка в качестве sh . | bash -e {0} |
Все | bash | Оболочка по умолчанию на платформах, отличных от Windows, с резервным вариантом sh . При указании оболочки Bash на Windows используется оболочка Bash, включенная в Git для Windows. | bash --noprofile --norc -eo pipefail {0} |
Все | pwsh | PowerShell Core. GitHub добавляет расширение .ps1 к имени скрипта. | pwsh -command ". '{0}'" |
Все | python | Выполняет команду Python. | python {0} |
Linux / macOS | sh | Резервное поведение для платформ, отличных от Windows, если оболочка не указана и bash не найден в пути. | sh -e {0} |
Windows | cmd | GitHub добавляет расширение .cmd к имени скрипта и заменяет {0} . | %ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}"" . |
Windows | pwsh | Это оболочка по умолчанию, используемая в Windows. PowerShell Core. GitHub добавляет расширение .ps1 к имени скрипта. Если в локальном средстве выполнения Windows не установлен PowerShell Core, будет использоваться PowerShell Desktop. | pwsh -command ". '{0}'" . |
Windows | powershell | PowerShell Desktop. GitHub добавляет расширение .ps1 к имени скрипта. | powershell -command ". '{0}'" . |
Кроме того, можно указать оболочку по умолчанию для всех run
шагов в задании или для всех run
шагов всего рабочего процесса. Дополнительные сведения см. в разделах defaults.run.shell
и jobs.<job_id>.defaults.run.shell
.
Пример. Выполнение команды с помощью Bash
steps:
- name: Display the path
shell: bash
run: echo $PATH
Пример. Выполнение команды с помощью Windows cmd
steps:
- name: Display the path
shell: cmd
run: echo %PATH%
Пример. Выполнение команды с помощью PowerShell Core
steps:
- name: Display the path
shell: pwsh
run: echo ${env:PATH}
Пример. Использование PowerShell Desktop для выполнения команды
steps:
- name: Display the path
shell: powershell
run: echo ${env:PATH}
Пример. Выполнение встроенного скрипта Python
steps:
- name: Display the path
shell: python
run: |
import os
print(os.environ['PATH'])
Пользовательская оболочка
Вы можете задать для значения shell
строку шаблона с помощью command [options] {0} [more_options]
. GitHub интерпретирует первое слово строки, отделенное пробелом, как команду и вставляет имя файла для временного скрипта в {0}
.
Например:
steps:
- name: Display the environment variables and their values
shell: perl {0}
run: |
print %ENV
Используемая команда, в этом примере perl
, должна быть установлена в средстве выполнения.
Коды выхода и настройки действий в случае ошибок
Для встроенных ключевых слов оболочки мы предоставляем следующие значения по умолчанию, выполняемые средствами выполнения, размещенными на GitHub. Эти рекомендации следует использовать при выполнении скриптов оболочки.
-
bash
/sh
:- По умолчанию для обоих и
bash
для обоихsh
используется принудительное поведение сбоемset -e
. Приshell: bash
указании-o pipefail
также применяется для принудительного раннего выхода из конвейеров, которые создают состояние выхода, отличного от нуля. - Вы можете получить полный контроль над параметрами оболочки, указав строку шаблона для параметров оболочки. Например,
bash {0}
. sh
-например, оболочки выходят с кодом выхода последней команды, выполняемой в скрипте, которая также является поведением по умолчанию для действий. Средство выполнения сообщит о состоянии шага (сбой/успешно) в зависимости от этого кода выхода.
- По умолчанию для обоих и
-
powershell
/pwsh
- Используйте завершение работы при первой ошибке по возможности. Для
pwsh
и встроенной оболочкиpowershell
мы добавим$ErrorActionPreference = 'stop'
к содержимому скрипта. - Мы добавляем
if ((Test-Path -LiteralPath variable:\LASTEXITCODE)) { exit $LASTEXITCODE }
к скриптам PowerShell, чтобы состояния действий отражали последний код выхода скрипта. - Пользователи всегда могут отказаться от использования встроенной оболочки и предоставить настраиваемый параметр оболочки, например:
pwsh -File {0}
илиpowershell -Command "& '{0}'"
, в зависимости от необходимости.
- Используйте завершение работы при первой ошибке по возможности. Для
-
cmd
- Кажется, что единственный способ настроить завершение работы при первой ошибке, — написать скрипт для проверки каждого кода ошибки и соответствующего реагирования. Так как мы не можем предоставить это поведение по умолчанию, необходимо записать это поведение в скрипт.
cmd.exe
завершит работу с уровнем ошибки последней выполняемой программы и вернет код ошибки средству выполнения. Это поведение внутренне согласуется с предыдущим поведением по умолчаниюsh
иpwsh
и являетсяcmd.exe
по умолчанию, поэтому это поведение остается неизменным.
jobs.<job_id>.steps[*].with
map
параметров ввода, определяемых действием. Каждый параметр ввода представляет собой пару "ключ-значение". Параметры ввода задаются как переменные среды. Переменная имеет префикс INPUT_
и преобразуется в верхний регистр.
Входные параметры, определенные для контейнера Docker, должны использоваться args
. Дополнительные сведения см. в разделе jobs.<job_id>.steps[*].with.args
.
Пример jobs.<job_id>.steps[*].with
Определяет три входных параметра (first_name
, middle_name
и last_name
), определенные действием hello_world
. Эти входные переменные будут доступны для действия hello-world
как переменные среды INPUT_FIRST_NAME
, INPUT_MIDDLE_NAME
и INPUT_LAST_NAME
.
jobs:
my_first_job:
steps:
- name: My first step
uses: actions/hello_world@main
with:
first_name: Mona
middle_name: The
last_name: Octocat
jobs.<job_id>.steps[*].with.args
Строка string
, определяющая входные данные для контейнера Docker. GitHub передает args
в ENTRYPOINT
контейнера при запуске контейнера. array of strings
не поддерживается этим параметром. Один аргумент, содержащий пробелы, должен быть окружен двойными кавычками ""
.
Пример jobs.<job_id>.steps[*].with.args
steps:
- name: Explain why this job ran
uses: octo-org/action-name@main
with:
entrypoint: /bin/echo
args: The ${{ github.event_name }} event triggered this step.
args
используются вместо инструкции CMD
в Dockerfile
. Если вы используете CMD
в Dockerfile
, следуйте этим рекомендациям, упорядоченным по предпочтительности:
- Задокументируйте обязательные аргументы в README действия и опустите их из инструкции
CMD
. - Используйте значения по умолчанию, позволяющие использовать действие без указания
args
. - Если действие предоставляет флаг
--help
или что-то подобное, используйте его по умолчанию, чтобы действие документировало само себя.
jobs.<job_id>.steps[*].with.entrypoint
Переопределяет параметр ENTRYPOINT
Docker в Dockerfile
или задает его, если он еще не был указан. В отличие от инструкции Docker ENTRYPOINT
, которая имеет форму оболочки и выполнения, ключевое слово entrypoint
принимает только одну строку, определяющую исполняемый файл для запуска.
Пример jobs.<job_id>.steps[*].with.entrypoint
steps:
- name: Run a custom command
uses: octo-org/action-name@main
with:
entrypoint: /a/different/executable
Ключевое слово entrypoint
предназначено для использования с действиями контейнера Docker, но его также можно использовать с действиями JavaScript, которые не определяют входные данные.
jobs.<job_id>.steps[*].env
Задает переменные для шагов, используемых в среде запуска. Можно также задать переменные для всего рабочего процесса или задания. Дополнительные сведения см. в разделах env
и jobs.<job_id>.env
.
При определении нескольких переменных среды с тем же именем GitHub использует самую конкретную переменную. Например, переменная среды, определенная на шаге, переопределяет переменные задания и среды рабочего процесса с тем же именем, а шаг выполняется. Переменная среды, определенная для задания, переопределяет переменную рабочего процесса с тем же именем, а задание выполняется.
Общедоступные действия могут указывать ожидаемые переменные в файле README. Если вы задаете секретное или конфиденциальное значение, например пароль или маркер, необходимо задать секреты с помощью контекста secrets
. Дополнительные сведения см. в разделе Доступ к контекстной информации о запусках рабочих процессов.
Пример jobs.<job_id>.steps[*].env
steps:
- name: My first action
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
FIRST_NAME: Mona
LAST_NAME: Octocat
jobs.<job_id>.steps[*].continue-on-error
Предотвращает сбой задания при сбое шага. Задайте значение true
, чтобы задание считалось выполненным при сбое этого шага.
jobs.<job_id>.steps[*].timeout-minutes
Максимальное количество минут для выполнения шага перед завершением процесса.
Дробные значения не поддерживаются. timeout-minutes
должно быть положительным целым числом.
jobs.<job_id>.timeout-minutes
Максимальное количество минут, в течение которых задание должно выполняться, пока GitHub автоматически не отменит его. Значение по умолчанию: 360
Если время ожидания превышает ограничение по времени выполнения задания для средства выполнения, задание будет отменено, когда будет достигнуто ограничение времени выполнения. Дополнительные сведения об ограничениях времени выполнения задания см. в разделе [AUTOTITLE для GitHubразмещенных в среде runner и Ограничения использования, выставление счетов и администрирование](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#usage-limits) для ограничения использования локального runner.
Note
Срок действия GITHUB_TOKEN
истекает при завершении задания или в течение не более 24 часов. Если время ожидания задания больше 24 часов, маркер может быть ограничивающим фактором. Дополнительные сведения об этом GITHUB_TOKEN
см. в разделе Автоматическая проверка подлинности токенов.
jobs.<job_id>.strategy
Используйте jobs.<job_id>.strategy
для применения стратегии матрицы к заданиям. Стратегия матрицы позволяет использовать переменные в одном определении задания для автоматического создания нескольких выполнений заданий, основанных на сочетаниях переменных. Например, можно использовать стратегию матрицы для тестирования кода в нескольких версиях языка или в нескольких операционных системах. Дополнительные сведения см. в разделе Выполнение вариантов заданий в рабочем процессе.
jobs.<job_id>.strategy.matrix
Используйте jobs.<job_id>.strategy.matrix
для создания матрицы различных конфигураций заданий В матрице определите одну или несколько переменных, за которыми следует массив значений. Например, в указанной ниже матрице есть переменная под именем version
со значением [10, 12, 14]
и переменная под именем os
со значением [ubuntu-latest, windows-latest]
:
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
Задание будет выполняться для каждой возможной комбинации переменных. В этом примере рабочий процесс будет выполнять шесть заданий, по одному для каждой комбинации переменных os
и version
.
По умолчанию GitHub Enterprise Server максимизирует количество параллельно выполняемых заданий в зависимости от доступности средства выполнения. Порядок переменных в матрице определяет порядок создания заданий. Первая переменная, которую вы определите, будет первым заданием, созданным в ходе выполнения рабочего процесса. Например, указанная выше матрица создаст задания в следующем порядке:
{version: 10, os: ubuntu-latest}
{version: 10, os: windows-latest}
{version: 12, os: ubuntu-latest}
{version: 12, os: windows-latest}
{version: 14, os: ubuntu-latest}
{version: 14, os: windows-latest}
Матрица создаст не более 256 заданий для каждого выполнения рабочего процесса. Это ограничение применяется как к размещенным в GitHub Enterprise Server, так и к локальным средствам выполнения.
Переменные, которые вы определяете, становятся свойствами в контексте matrix
, и можно ссылаться на это свойство в других областях файла рабочего процесса. В этом примере можно использовать matrix.version
и matrix.os
, чтобы получить доступ к текущим значениям version
и os
, которые использует задание. Дополнительные сведения см. в разделе «Доступ к контекстной информации о запусках рабочих процессов».
Пример. Использование матрицы с одним измерением
Можно указать одну переменную для создания одномерной матрицы.
Например, следующий рабочий процесс определяет переменную version
со значениями [10, 12, 14]
. Рабочий процесс будет выполнять три задания, по одному для каждого значения в переменной. Каждое задание будет получать доступ к значению version
через контекст matrix.version
и передавать значение node-version
в действие actions/setup-node
.
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
steps:
- uses: actions/setup-node@v4
with:
node-version: ${{ matrix.version }}
Пример. Использование матрицы с несколькими измерениями
Для создания многомерной матрицы можно указать несколько переменных. Задание будет выполняться для каждой возможной комбинации переменных.
Например, для следующего рабочего процесса устанавливаются две переменные:
- Две операционные системы, указанные в переменной
os
- Три версии Node.js, указанные в переменной
version
Рабочий процесс будет выполнять шесть заданий, по одному для каждой комбинации переменных os
и version
. В каждом задании параметру runs-on
присваивается текущее значение os
и передается текущее значение version
в действие actions/setup-node
.
jobs:
example_matrix:
strategy:
matrix:
os: [ubuntu-22.04, ubuntu-20.04]
version: [10, 12, 14]
runs-on: ${{ matrix.os }}
steps:
- uses: actions/setup-node@v4
with:
node-version: ${{ matrix.version }}
Конфигурация переменной в матрице может иметь значение array
object
s.
matrix:
os:
- ubuntu-latest
- macos-latest
node:
- version: 14
- version: 16
env: NODE_OPTIONS=--openssl-legacy-provider
Эта матрица создает 4 задания с соответствующими контекстами.
- matrix.os: ubuntu-latest
matrix.node.version: 14
- matrix.os: ubuntu-latest
matrix.node.version: 16
matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider
- matrix.os: macos-latest
matrix.node.version: 14
- matrix.os: macos-latest
matrix.node.version: 16
matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider
Пример. Использование контекстов для создания матриц
Контексты можно использовать для создания матриц. Дополнительные сведения о контекстах см. в разделе "Доступ к контекстной информации о запусках рабочих процессов".
Например, следующий рабочий процесс активирует событие repository_dispatch
и использует сведения из его полезных данных для построения матрицы. При создании события диспетчеризации репозитория с полезными данными, как показано ниже, переменная version
матрицы будет иметь значение [12, 14, 16]
. Дополнительные сведения об триггере repository_dispatch
см. в разделе "События, инициирующие рабочие процессы".
{
"event_type": "test",
"client_payload": {
"versions": [12, 14, 16]
}
}
on:
repository_dispatch:
types:
- test
jobs:
example_matrix:
runs-on: ubuntu-latest
strategy:
matrix:
version: ${{ github.event.client_payload.versions }}
steps:
- uses: actions/setup-node@v4
with:
node-version: ${{ matrix.version }}
jobs.<job_id>.strategy.matrix.include
Используйте jobs.<job_id>.strategy.matrix.include
для разворачивания существующих конфигураций матрицы или добавления новых конфигураций. Значение include
является списком объектов.
Для каждого объекта в списке include
пары ключ:значение в объекте будут добавлены к каждой из комбинаций матриц, если ни одна из пар ключ:значение не перезаписывает какие-либо исходные значения матрицы. Если объект не может быть добавлен в какие-либо комбинации матриц, будет создана новая. Обратите внимание, что исходные матричные значения не будут перезаписаны, но добавленные матричные значения могут быть перезаписаны.
Например, эта матрица:
strategy:
matrix:
fruit: [apple, pear]
animal: [cat, dog]
include:
- color: green
- color: pink
animal: cat
- fruit: apple
shape: circle
- fruit: banana
- fruit: banana
animal: cat
приведет к шести заданиям со следующими комбинациями матриц:
{fruit: apple, animal: cat, color: pink, shape: circle}
{fruit: apple, animal: dog, color: green, shape: circle}
{fruit: pear, animal: cat, color: pink}
{fruit: pear, animal: dog, color: green}
{fruit: banana}
{fruit: banana, animal: cat}
следуя этой логике:
{color: green}
добавляется ко всем исходным комбинациям матриц, так как его можно добавить без перезаписи любой части исходных комбинаций.{color: pink, animal: cat}
добавляетcolor:pink
только к исходным комбинациям матриц, которые включаютanimal: cat
. Это перезаписываетcolor: green
, добавленный предыдущей записьюinclude
.{fruit: apple, shape: circle}
добавляетshape: circle
только к исходным комбинациям матриц, которые включаютfruit: apple
.{fruit: banana}
невозможно добавить ни в какую исходную комбинацию матриц без перезаписи значения, поэтому он добавляется в качестве дополнительной комбинации матриц.{fruit: banana, animal: cat}
невозможно добавить ни в какую исходную комбинацию матриц без перезаписи значения, поэтому он добавляется в качестве дополнительной комбинации матриц. Он не добавляется к комбинации матриц{fruit: banana}
, так как эта комбинация не была одной из исходных комбинаций матриц.
Пример. Развертывание конфигураций
Например, следующий рабочий процесс будет выполнять четыре задания, по одному для каждого сочетания os
и node
. Если выполняется задание для значения windows-latest
параметра os
и значения 16
параметра node
, в задание будет включена дополнительная переменная npm
со значением 6
.
jobs:
example_matrix:
strategy:
matrix:
os: [windows-latest, ubuntu-latest]
node: [14, 16]
include:
- os: windows-latest
node: 16
npm: 6
runs-on: ${{ matrix.os }}
steps:
- uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node }}
- if: ${{ matrix.npm }}
run: npm install -g npm@${{ matrix.npm }}
- run: npm --version
Пример. Добавление конфигураций
Например, в этой матрице будет выполняться 10 заданий, по одному для каждого сочетания os
и version
в матрице, а также еще одно задание для windows-latest
со значением os
и 17
со значением version
.
jobs:
example_matrix:
strategy:
matrix:
os: [macos-latest, windows-latest, ubuntu-latest]
version: [12, 14, 16]
include:
- os: windows-latest
version: 17
Если не указать переменные матрицы, будут выполняться все конфигурации в include
. Например, следующий рабочий процесс выполнит два задания, по одному для каждого элемента include
. Это позволяет использовать не полностью заполненную матрицу.
jobs:
includes_only:
runs-on: ubuntu-latest
strategy:
matrix:
include:
- site: "production"
datacenter: "site-a"
- site: "staging"
datacenter: "site-b"
jobs.<job_id>.strategy.matrix.exclude
Чтобы удалить конкретные конфигурации, определенные в матрице, используйте jobs.<job_id>.strategy.matrix.exclude
. Исключенная конфигурация должна иметь хотя бы частичное совпадение, чтобы ее можно было исключить. Например, следующий рабочий процесс будет выполнять девять заданий: одно задание для каждой из 12 конфигураций, минус одно исключенное задание, которое совпадает с {os: macos-latest, version: 12, environment: production}
, и два исключенных задания, которые совпадают с {os: windows-latest, version: 16}
.
strategy:
matrix:
os: [macos-latest, windows-latest]
version: [12, 14, 16]
environment: [staging, production]
exclude:
- os: macos-latest
version: 12
environment: production
- os: windows-latest
version: 16
runs-on: ${{ matrix.os }}
Note
Все include
сочетания обрабатываются после exclude
. Это позволяет использовать include
для добавления обратных комбинаций, которые были ранее исключены.
jobs.<job_id>.strategy.fail-fast
Можно управлять обработкой сбоев заданий с помощью jobs.<job_id>.strategy.fail-fast
и jobs.<job_id>.continue-on-error
.
jobs.<job_id>.strategy.fail-fast
применяется ко всему тому. Если jobs.<job_id>.strategy.fail-fast
задано значение true
или его выражение оценивается true
, GitHub Enterprise Server отменит все выполняемые и очередные задания в матрице, если любое задание в матрице завершается ошибкой. По умолчанию свойство имеет значение true
.
jobs.<job_id>.continue-on-error
применяется к одному заданию. Если jobs.<job_id>.continue-on-error
имеет значение true
, другие задания в матрице будут продолжать выполняться, даже если задание с jobs.<job_id>.continue-on-error: true
завершается сбоем.
Можно использовать jobs.<job_id>.strategy.fail-fast
и jobs.<job_id>.continue-on-error
совместно. Например, следующий рабочий процесс запустит четыре задания. Для каждого задания continue-on-error
определяется значением matrix.experimental
. При сбое любого из заданий с continue-on-error: false
все выполняемые или помещенные в очередь задания будут отменены. При сбое задания с continue-on-error: true
другие задания не будут затронуты.
jobs:
test:
runs-on: ubuntu-latest
continue-on-error: ${{ matrix.experimental }}
strategy:
fail-fast: true
matrix:
version: [6, 7, 8]
experimental: [false]
include:
- version: 9
experimental: true
jobs.<job_id>.strategy.max-parallel
По умолчанию GitHub Enterprise Server максимизирует количество параллельно выполняемых заданий в зависимости от доступности средства выполнения. Для настройки максимального числа заданий, которые могут выполняться одновременно при применении стратегии задания matrix
, используйте jobs.<job_id>.strategy.max-parallel
.
Например, следующий рабочий процесс будет выполнять не более двух заданий одновременно, даже если для одновременного выполнения всех шести заданий доступны средства выполнения.
jobs:
example_matrix:
strategy:
max-parallel: 2
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
jobs.<job_id>.continue-on-error
Предотвращает сбой выполнения рабочего процесса при сбое задания. Установите значение true
, чтобы разрешить выполнение рабочего процесса в случае сбоя этого задания.
Пример. Предотвращение сбоя рабочего процесса в случае сбоя определенного задания матрицы
Можно разрешить сбой определенных заданий в матрице без сбоя всего рабочего процесса. Например, можно разрешить сбой экспериментального задания, у которого для node
задано 15
, без сбоя рабочего процесса.
runs-on: ${{ matrix.os }}
continue-on-error: ${{ matrix.experimental }}
strategy:
fail-fast: false
matrix:
node: [13, 14]
os: [macos-latest, ubuntu-latest]
experimental: [false]
include:
- node: 15
os: ubuntu-latest
experimental: true
jobs.<job_id>.container
Note
Если в рабочих процессах используются действия контейнеров Docker, контейнеры заданий или контейнеры служб, необходимо использовать средство выполнения Linux:
- При использовании размещенных в GitHub средств выполнения необходимо применять средство выполнения Ubuntu.
- Если вы применяете локальные средства выполнения, необходимо использовать компьютер Linux в качестве средства выполнения, а Docker нужно установить.
Используйте jobs.<job_id>.container
для создания контейнера для выполнения всех этапов задания, для которых еще не указан контейнер. При наличии этапов, которые используют действия скрипта и контейнера, действия контейнера будут выполняться как одноуровневые контейнеры в той же сети с теми же подключениями томов.
Если container
не задан, все этапы будут выполняться непосредственно на узле, указанном, runs-on
, если только этап не относится к действию, настроенному на выполнение в контейнере.
Note
Оболочка по умолчанию для run
шагов внутри контейнера sh
вместо bash
. Это значение может быть изменено на jobs.<job_id>.defaults.run
или jobs.<job_id>.steps[*].shell
.
Пример. Выполнение задания в контейнере
name: CI on: push: branches: [ main ] jobs: container-test-job: runs-on: ubuntu-latest container: image: node:18 env: NODE_ENV: development ports: - 80 volumes: - my_docker_volume:/volume_mount options: --cpus 1 steps: - name: Check for dockerenv file run: (ls /.dockerenv && echo Found dockerenv) || (echo No dockerenv)
name: CI
on:
push:
branches: [ main ]
jobs:
container-test-job:
runs-on: ubuntu-latest
container:
image: node:18
env:
NODE_ENV: development
ports:
- 80
volumes:
- my_docker_volume:/volume_mount
options: --cpus 1
steps:
- name: Check for dockerenv file
run: (ls /.dockerenv && echo Found dockerenv) || (echo No dockerenv)
При указании только образа контейнера можно опустить ключевое слово image
.
jobs:
container-test-job:
runs-on: ubuntu-latest
container: node:18
jobs.<job_id>.container.image
Используйте jobs.<job_id>.container.image
для определения образа Docker, который будет использоваться в качестве контейнера для выполнения действия. Значением может быть имя образа Docker Hub или имя реестра.
jobs.<job_id>.container.credentials
Если реестру контейнеров образа требуется проверка подлинности для извлечения образа, можно использовать jobs.<job_id>.container.credentials
, чтобы настроить map
для username
и password
. Учетные данные являются теми же значениями, которые будут предоставлены команде docker login
.
Пример: определение учетных данных для реестра контейнеров
container:
image: ghcr.io/owner/image
credentials:
username: ${{ github.actor }}
password: ${{ secrets.github_token }}
jobs.<job_id>.container.env
Используйте jobs.<job_id>.container.env
для задания map
переменных среды в контейнере.
jobs.<job_id>.container.ports
Используйте jobs.<job_id>.container.ports
для задания array
портов для использования в контейнере.
jobs.<job_id>.container.volumes
Используйте jobs.<job_id>.container.volumes
для задания array
томов, которые будет использовать контейнер. Тома можно использовать для совместного использования данных между службами или другими этапами в задании. Можно указать именованные тома Docker, анонимные тома Docker или подключения привязок на узле.
Чтобы указать том, укажите путь к источнику и назначению:
<source>:<destinationPath>
.
<source>
— это имя тома или абсолютный путь на хост-компьютере, а <destinationPath>
— это абсолютный путь в контейнере.
Пример. Подключение томов в контейнере
volumes:
- my_docker_volume:/volume_mount
- /data/my_data
- /source/directory:/destination/directory
jobs.<job_id>.container.options
Используйте jobs.<job_id>.container.options
для настройки дополнительных параметров ресурса контейнера Docker. Список параметров см. в статье "Параметры docker create
".
Warning
Параметры --network
и --entrypoint
параметры не поддерживаются.
jobs.<job_id>.services
Note
Если в рабочих процессах используются действия контейнеров Docker, контейнеры заданий или контейнеры служб, необходимо использовать средство выполнения Linux:
- При использовании размещенных в GitHub средств выполнения необходимо применять средство выполнения Ubuntu.
- Если вы применяете локальные средства выполнения, необходимо использовать компьютер Linux в качестве средства выполнения, а Docker нужно установить.
Используется для размещения контейнеров служб для задания в рабочем процессе. Контейнеры служб полезны для создания баз данных или служб кэша, таких как Redis. Средство выполнения автоматически создает сеть Docker и управляет жизненным циклом контейнеров служб.
Если вы настраиваете задание для выполнения в контейнере или шаг использует действия контейнера, вам не нужно сопоставлять порты для доступа к службе или действию. Docker автоматически предоставляет все порты между контейнерами в одной сети моста, определяемой пользователем Docker. Вы можете напрямую ссылаться на контейнер службы по имени узла. Имя узла автоматически сопоставляется с именем метки, настроенной для службы в рабочем процессе.
Если вы настраиваете задание для запуска непосредственно на компьютере средства выполнения, а шаг не использует действие контейнера, необходимо сопоставить все необходимые порты контейнера службы Docker с узлом Docker (компьютер средства выполнения). Доступ к контейнеру службы можно получить с помощью localhost и сопоставленного порта.
Дополнительные сведения о различиях между контейнерами сетевых служб см. в разделе Сведения о контейнерах служб.
Пример. Использование localhost
В этом примере создаются две службы: nginx и redis. При указании порта контейнера, но не узла порт контейнера случайным образом назначается свободному порту на узле. GitHub задает назначенный порт узла в контексте ${{job.services.<service_name>.ports}}
. В этом примере можно получить доступ к портам узла службы с помощью контекстов ${{ job.services.nginx.ports['80'] }}
и ${{ job.services.redis.ports['6379'] }}
.
services:
nginx:
image: nginx
# Map port 8080 on the Docker host to port 80 on the nginx container
ports:
- 8080:80
redis:
image: redis
# Map random free TCP port on Docker host to port 6379 on redis container
ports:
- 6379/tcp
steps:
- run: |
echo "Redis available on 127.0.0.1:${{ job.services.redis.ports['6379'] }}"
echo "Nginx available on 127.0.0.1:${{ job.services.nginx.ports['80'] }}"
jobs.<job_id>.services.<service_id>.image
Образ Docker для использования в качестве контейнера для выполнения действия. Значением может быть имя образа Docker Hub или имя реестра.
Если jobs.<job_id>.services.<service_id>.image
назначена пустая строка, служба не запустится. Это можно использовать для настройки условных служб, как показано в следующем примере.
services:
nginx:
image: ${{ options.nginx == true && 'nginx' || '' }}
jobs.<job_id>.services.<service_id>.credentials
Если реестру контейнеров образа требуется проверка подлинности для извлечения образа, можно использовать jobs.<job_id>.container.credentials
, чтобы настроить map
для username
и password
. Учетные данные являются теми же значениями, которые будут предоставлены команде docker login
.
Пример jobs.<job_id>.services.<service_id>.credentials
services:
myservice1:
image: ghcr.io/owner/myservice1
credentials:
username: ${{ github.actor }}
password: ${{ secrets.github_token }}
myservice2:
image: dockerhub_org/myservice2
credentials:
username: ${{ secrets.DOCKER_USER }}
password: ${{ secrets.DOCKER_PASSWORD }}
jobs.<job_id>.services.<service_id>.env
Задает map
переменных среды в контейнере службы.
jobs.<job_id>.services.<service_id>.ports
Задает array
портов для предоставления в контейнере службы.
jobs.<job_id>.services.<service_id>.volumes
Задает array
тома для используемого контейнера службы. Тома можно использовать для совместного использования данных между службами или другими этапами в задании. Можно указать именованные тома Docker, анонимные тома Docker или подключения привязок на узле.
Чтобы указать том, укажите путь к источнику и назначению:
<source>:<destinationPath>
.
<source>
— это имя тома или абсолютный путь на хост-компьютере, а <destinationPath>
— это абсолютный путь в контейнере.
Пример jobs.<job_id>.services.<service_id>.volumes
volumes:
- my_docker_volume:/volume_mount
- /data/my_data
- /source/directory:/destination/directory
jobs.<job_id>.services.<service_id>.options
Дополнительные параметры ресурса контейнера Docker. Список параметров см. в разделе docker create
параметров.
Warning
Параметр --network
не поддерживается.
jobs.<job_id>.uses
Расположение и версия повторно используемого файла рабочего процесса для запуска в качестве задания. Используйте один из следующих синтаксисов:
{owner}/{repo}/.github/workflows/{filename}@{ref}
для повторно используемых рабочих процессов в public and internal репозитории../.github/workflows/{filename}
для повторно используемых рабочих процессов в одном репозитории.
В первом варианте {ref}
может быть SHA, тег выпуска или имя ветви. Если тег выпуска и ветвь имеют то же имя, тег выпуска имеет приоритет над именем ветви. Использование sha фиксации является самым безопасным вариантом для стабильности и безопасности. Дополнительные сведения см. в разделе «Защита системы безопасности для GitHub Actions».
Если используется второй параметр синтаксиса (без {owner}/{repo}
и) вызываемого рабочего процесса происходит из той же фиксации, что и @{ref}
рабочий процесс вызывающего объекта. Префиксы ссылок, такие как refs/heads
и refs/tags
не допускаются. В этом ключевом слове нельзя использовать контексты или выражения.
Пример jobs.<job_id>.uses
jobs:
call-workflow-1-in-local-repo:
uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89
call-workflow-2-in-local-repo:
uses: ./.github/workflows/workflow-2.yml
call-workflow-in-another-repo:
uses: octo-org/another-repo/.github/workflows/workflow.yml@v1
Дополнительные сведения см. в разделе Повторное использование рабочих процессов.
jobs.<job_id>.with
Если задание используется для вызова многократно используемого рабочего процесса, можно использовать with
для предоставления карты входных данных, передаваемых в вызываемый рабочий процесс.
Все входные данные, которые вы передаете, должны соответствовать спецификациям ввода, определенным в вызываемом рабочем процессе.
В отличие от jobs.<job_id>.steps[*].with
того, какие входные данные передаются jobs.<job_id>.with
, недоступны в виде переменных среды в вызываемом рабочем процессе. Вместо этого можно ссылаться на входные данные с помощью контекста inputs
.
Пример jobs.<job_id>.with
jobs:
call-workflow:
uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main
with:
username: mona
jobs.<job_id>.with.<input_id>
Пара, состоящая из строкового идентификатора для входных данных и значения входных данных. Идентификатор должен соответствовать имени входных данных, определенных on.workflow_call.inputs.<inputs_id>
в вызываемом рабочем процессе. Тип данных значения должен соответствовать типу, определенному on.workflow_call.inputs.<input_id>.type
в вызываемом рабочем процессе.
Допустимые контексты выражений: github
и needs
.
jobs.<job_id>.secrets
Если задание используется для вызова многократно используемого рабочего процесса, можно использовать secrets
для предоставления карты секретов, передаваемых в вызываемый рабочий процесс.
Все секретные данные, которые вы передаете, должны соответствовать именам, определенным в вызываемом рабочем процессе.
Пример jobs.<job_id>.secrets
jobs:
call-workflow:
uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main
secrets:
access-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
jobs.<job_id>.secrets.inherit
Используйте ключевое слово inherit
для передачи всех секретов вызывающего рабочего процесса в вызываемой рабочий процесс. Сюда входят все секреты, к которым у вызывающего рабочего процесса есть доступ, то есть секреты организации, репозитория и среды. Ключевое слово inherit
можно использовать для передачи секретов между репозиториями в одной организации или между организациями в пределах одного предприятия.
Пример jobs.<job_id>.secrets.inherit
on:
workflow_dispatch:
jobs:
pass-secrets-to-workflow:
uses: ./.github/workflows/called-workflow.yml
secrets: inherit
on:
workflow_call:
jobs:
pass-secret-to-action:
runs-on: ubuntu-latest
steps:
- name: Use a repo or org secret from the calling workflow.
run: echo ${{ secrets.CALLING_WORKFLOW_SECRET }}
jobs.<job_id>.secrets.<secret_id>
Пара, состоящая из строкового идентификатора для секрета и значения секрета. Идентификатор должен соответствовать имени секрета, определенного on.workflow_call.secrets.<secret_id>
в вызываемом рабочем процессе.
Допустимые контексты выражений: github
, needs
и secrets
.
Памятка по шаблонам фильтров
Специальные символы можно использовать в фильтрах путей, ветвей и тегов.
*
: соответствует нулю или нескольким символам, но не соответствует символу/
. Например,Octo*
соответствуетOctocat
.**
: соответствует нулю или более символам.?
: соответствует нулю или одному из предыдущих символов.+
: соответствует одному или нескольким предыдущим символам.[]
Соответствует одному буквенно-цифровому символу, указанному в скобках или включенным в диапазоны. Диапазоны могут включать толькоa-z
,A-Z
и0-9
. Например, диапазон[0-9a-z]
соответствует любой цифре или строчной букве. Например,[CB]at
соответствуетCat
илиBat
, а[1-2]00
соответствует100
и200
.!
: в начале шаблона приводит к отмене предыдущих положительных шаблонов. Если не является первым символом, не имеет особого значения.
Символы *
, [
и !
являются специальными символами в YAML. Если вы начинаете шаблон с *
, [
или !
, необходимо заключить шаблон в кавычки. Кроме того, при использовании последовательности потоков с шаблоном, содержащим [
и (или) ]
шаблон должен быть заключен в кавычки.
# Valid
paths:
- '**/README.md'
# Invalid - creates a parse error that
# prevents your workflow from running.
paths:
- **/README.md
# Valid
branches: [ main, 'release/v[0-9].[0-9]' ]
# Invalid - creates a parse error
branches: [ main, release/v[0-9].[0-9] ]
Дополнительные сведения о синтаксисе фильтра ветвей, тегов и путей см. в разделе on.<push>.<branches|tags>
,on.<pull_request>.<branches|tags>
а on.<push|pull_request>.paths
также .
Шаблоны для сопоставления ветвей и тегов
Расписание | Description | Примеры совпадений |
---|---|---|
feature/* | Подстановочный знак * соответствует любому символу, но не соответствует косой черте (/ ). | feature/my-branch feature/ |
feature/** | Подстановочный знак ** соответствует любому символу, включая косую черту (/ ), в именах ветвей и тегов. | feature/ feature/ feature/ |
main releases/ | Соответствует точному имени ветви или тега. | main releases/ |
'*' | Соответствует всем именам ветвей и тегов, которые не содержат косую черту (/ ). Символ * является специальным символом в YAML. При запуске шаблона с * необходимо использовать кавычки. | main releases |
'**' | Соответствует всем именам ветвей и тегов. Это поведение по умолчанию, если вы не используете фильтр branches или tags . | all/the/branches every/tag |
'*feature' | Символ * является специальным символом в YAML. При запуске шаблона с * необходимо использовать кавычки. | mona-feature feature ver-10-feature |
v2* | Соответствует именам ветвей и тегов, начинающимся с v2 . | v2 v2.0 v2.9 |
v[12].[0-9]+.[0-9]+ | Соответствует всем ветвям и тегам семантического управления версиями с основной версией 1 или 2. | v1.10.1 v2.0.0 |
Шаблоны для сопоставления путей к файлам
Шаблоны путей должны соответствовать всему пути и начинаться с корневого каталога репозитория.
Расписание | Описание совпадений | Примеры совпадений |
---|---|---|
'*' | Подстановочный знак * соответствует любому символу, но не соответствует косой черте (/ ). Символ * является специальным символом в YAML. При запуске шаблона с * необходимо использовать кавычки. | README.md server.rb |
'*.jsx?' | Символ ? соответствует нулю или одному из предыдущих символов. | page.js page.jsx |
'**' | Подстановочный знак ** соответствует любому символу, включая косую черту (/ ). Это поведение по умолчанию, если вы не используете фильтр path . | all/the/files.md |
'*.js' | Подстановочный знак * соответствует любому символу, но не соответствует косой черте (/ ). Соответствует всем файлам .js в корне репозитория. | app.js index.js |
'**.js' | Соответствует всем файлам .js в репозитории. | index.js js/index.js src/js/app.js |
docs/* | Все файлы в корневом каталоге docs только в корне репозитория. | docs/README.md docs/file.txt |
docs/** | Все файлы в каталоге docs и его подкаталогах в корне репозитория. | docs/README.md docs/ |
docs/**/*.md | Файл с суффиксом .md в любом месте каталога docs . | docs/README.md docs/ docs/ |
'**/docs/**' | Любые файлы в каталоге docs в любом месте репозитория. | docs/hello.md dir/ space/ |
'**/README.md' | Файл README.md в любом месте репозитория. | README.md js/README.md |
'**/*src/**' | Любой файл в папке с суффиксом src в любом месте репозитория. | a/src/app.js my-src/ |
'**/*-post.md' | Файл с суффиксом -post.md в любом месте репозитория. | my-post.md path/ |
'**/migrate-*.sql' | Файл с префиксом migrate- и суффиксом .sql в любом месте репозитория. | migrate-10909.sql db/ db/ |
'*.md' '!README.md' | Использование восклицательного знака (! ) перед шаблоном отменяет его. Если файл соответствует шаблону, а также соответствует отрицательному шаблону, определенному позже в файле, файл не будет включен. | hello.md Не совпадает README.md docs/hello.md |
'*.md' '!README.md' README* | Шаблоны проверяются последовательно. Шаблон, который отрицает предыдущий шаблон, будет повторно включать пути к файлам. | hello.md README.md README.doc |