# Синтаксис рабочего процесса для GitHub Actions Рабочий процесс — это настраиваемый автоматизированный процесс, состоящий из одного или нескольких заданий. Чтобы определить конфигурацию рабочего процесса, необходимо создать YAML-файл. > \[!NOTE] > GitHub Enterprise Serverразмещенные в данный момент средства выполнения не поддерживаются в GitHub. ## Сведения о синтаксисе YAML для рабочих процессов Файлы рабочего процесса используют синтаксис YAML и должны иметь расширение файла `.yml` или `.yaml`. Если вы не знакомы с YAML и хотите узнать больше, ознакомьтесь с разделом ["Сведения о YAML" в минутах](https://learnxinyminutes.com/docs/yaml/) Y. Файлы рабочего процесса необходимо хранить в каталоге `.github/workflows` репозитория. ## `name` Имя рабочего процесса. GitHub отображает имена рабочих процессов на вкладке "Действия" репозитория. Если не указано `name`, GitHub отображает путь к файлу рабочего процесса относительно корневого каталога репозитория. ## `run-name` Имя рабочего процесса, созданное из рабочего процесса. GitHub отображает название запуска рабочего процесса в списке запущенных рабочих процессов на вкладке «Действия» вашего репозитория. Если `run-name` пропущено или это только пробел, то название запуска устанавливается на информацию, специфичную для события, для запуска рабочего процесса. Например, для рабочего процесса, активированного событием `push` или событием, оно устанавливается как сообщение фиксации или `pull_request` название запроса на вытягивание. Это значение может включать выражения и может ссылаться на [`github`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#github-context) них и [`inputs`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#inputs-context) контексты. ### Пример `run-name` ```yaml run-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }} ``` ## `on` Чтобы автоматически активировать рабочий процесс, используйте `on` для указания событий, которые могут привести к запуску рабочего процесса. Список доступных событий см. в разделе [События, инициирующие рабочие процессы](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows). Можно определить одно или несколько событий, которые могут активировать рабочий процесс или задать расписание времени. Можно также настроить рабочий процесс так, чтобы он выполнялся только для определенных файлов, тегов или изменений ветвей. Описание этих параметров приводится в следующих разделах. ### Использование одного события Например, рабочий процесс со следующим значением `on` будет выполняться при осуществлении отправки в любую ветвь в репозитории рабочего процесса: ```yaml on: push ``` ### Использование нескольких событий Можно указать одно или несколько событий. Например, рабочий процесс со следующим значением `on` будет выполняться при осуществлении отправки в любую ветвь в репозитории, или когда кто-то создает вилку репозитория: ```yaml on: [push, fork] ``` Если указано несколько событий, для активации рабочего процесса необходимо, чтобы произошло только одно из них. Если одновременно происходят несколько событий, активирующих рабочий процесс, будет активировано несколько выполнений рабочих процессов. ### Использование типов действий Некоторые события имеют типы действий, позволяющие лучше контролировать выполнение рабочего процесса. Используйте `on..types` для определения типа действия для события, которое активирует запуск рабочего процесса. Например, событие `issue_comment` имеет типы действий `created`, `edited` и `deleted`. Если рабочий процесс активируется в событии `label`, он будет выполняться при создании, изменении или удалении метки. Если указать тип действия `created` для события `label`, рабочий процесс будет запускаться при создании метки, но не при изменении или удалении метки. ```yaml on: label: types: - created ``` Если указать несколько типов действий, для активации рабочего процесса потребуется выполнить только один из этих типов действий. Если одновременно происходят несколько типов действий для событий, активирующих рабочий процесс, будет активировано несколько выполнений рабочих процессов. Например, следующий рабочий процесс активируется при открытии проблемы или добавлении для нее метки. Если открывается проблема с двумя метками, начинаются три запуска рабочего процесса: один для события открытия проблемы и два для двух событий проблем с метками. ```yaml on: issues: types: - opened - labeled ``` Дополнительные сведения о каждом событии и их типах действий см. в разделе [События, инициирующие рабочие процессы](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows). ### Использование фильтров Некоторые события имеют фильтры, позволяющие лучше контролировать выполнение рабочего процесса. Например, событие `push` имеет фильтр `branches`, из-за которого рабочий процесс выполняется только при отправке в ветвь, которая соответствует фильтру `branches`, а не при любой отправке. ```yaml on: push: branches: - main - 'releases/**' ``` ### Использование типов действий и фильтров с несколькими событиями Если вы указываете типы действий или фильтры для события и триггеры рабочего процесса для нескольких событий, необходимо настроить каждое событие отдельно. Необходимо добавить двоеточие (`:`) ко всем событиям, включая события без конфигурации. Например, рабочий процесс со следующим значением `on` будет выполняться в следующих случаях: * создание метки; * отправка в ветвь `main` в репозитории; * отправка в ветвь с поддержкой GitHub Pages. ```yaml on: label: types: - created push: branches: - main page_build: ``` ## `on..types` Используйте `on..types` для определения типа действия для события, которое активирует выполнение рабочего процесса. Большинство событий GitHub активируются несколькими типами действий. Например, `label` активируется, если метка имеет значение `created`, `edited` или `deleted`. Ключевое слово `types` позволяет сузить действие, которое приводит к выполнению рабочего процесса. Если только один тип действия активирует событие веб-перехватчика, ключевое слово `types` не требуется. Можно использовать массив событий `types`. Дополнительные сведения о каждом событии и их типах действий см. в разделе [События, инициирующие рабочие процессы](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows). ```yaml on: label: types: [created, edited] ``` ## `on..` При использовании событий `pull_request` и `pull_request_target` можно настроить выполнение рабочего процесса только для запросов на вытягивание, предназначенных для конкретных ветвей. Используйте фильтр `branches`, если требуется включить шаблоны имен ветвей или как включить, так и исключить их. Используйте фильтр `branches-ignore`, если требуется только исключить шаблоны имен ветвей. Для одного и того же события в рабочем процессе нельзя использовать фильтры `branches` и `branches-ignore` одновременно. Если вы определили и `branches`/`branches-ignore`, и [`paths`/`paths-ignore`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore), рабочий процесс будет запускаться только в случае, если выполнены оба фильтра. Ключевые слова `branches` и `branches-ignore` принимают стандартные маски, использующие такие символы, как `*`, `**`, `+`, `?`, `!` и другие, чтобы соответствовать нескольким именам ветвей. Если имя содержит любой из этих символов и требуется буквальное совпадение, необходимо экранировать каждый из этих специальных символов с помощью `\`. Дополнительные сведения о шаблонах глобов см. в [разделе AUTOTITLE](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet). ### Пример: включение ветвей Шаблоны, определенные в `branches`, оцениваются по имени ссылки Git. Например, указанный ниже рабочий процесс будет выполняться всякий раз, когда происходит событие `pull_request` для запроса на вытягивание, нацеленного на: * ветви с именем `main` (`refs/heads/main`); * ветви с именем `mona/octocat` (`refs/heads/mona/octocat`); * ветви, имя которой начинается с `releases/`, например `releases/10` (`refs/heads/releases/10`); ```yaml on: pull_request: # Sequence of patterns matched against refs/heads branches: - main - 'mona/octocat' - 'releases/**' ``` Не следует использовать фильтрацию пути или ветви, чтобы пропустить выполнение рабочего процесса, если рабочий процесс необходим для передачи перед слиянием. Дополнительные сведения см. в разделе \[AUTOTITLE и [Пропуск запусков рабочих процессов](/ru/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/skip-workflow-runs)]\(/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging). Если рабочий процесс пропускается из-за фильтрации ветвей, [фильтрации](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore) путей или [сообщения](/ru/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/skip-workflow-runs) фиксации, то проверки, связанные с этим рабочим процессом, останутся в состоянии "Ожидание". Запрос на включение внесенных изменений, требующий успешной проверки, будет заблокирован при слиянии. ### Пример исключения ветвей В случае соответствия шаблона `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`); ```yaml 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` соответствует положительному шаблону. ```yaml on: pull_request: branches: - 'releases/**' - '!releases/**-alpha' ``` ## `on.push.` При использовании события `push` можно настроить выполнение рабочего процесса в определенных ветвях или тегах. Используйте фильтр `branches`, если требуется включить шаблоны имен ветвей или как включить, так и исключить их. Используйте фильтр `branches-ignore`, если требуется только исключить шаблоны имен ветвей. Для одного и того же события в рабочем процессе нельзя использовать фильтры `branches` и `branches-ignore` одновременно. Используйте фильтр `tags`, если требуется включить шаблоны имен тегов или как включить, так и исключить их. Используйте фильтр `tags-ignore`, если требуется только исключить шаблоны имен тегов. Для одного и того же события в рабочем процессе нельзя использовать фильтры `tags` и `tags-ignore` одновременно. Если вы определяете только или `tags`/`tags-ignore`только`branches`/`branches-ignore`, рабочий процесс не будет выполняться для событий, влияющих на неопределенную ссылку на Git. Если определить ни одно `tags`/`tags-ignore` или`branches`/`branches-ignore`, рабочий процесс будет выполняться для событий, влияющих на ветви или теги. Если вы определили и `branches`/`branches-ignore`, и [`paths`/`paths-ignore`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore), рабочий процесс будет запускаться только в случае, если выполнены оба фильтра. Ключевые слова `branches`, `branches-ignore`, `tags`и `tags-ignore` принимают стандартные маски, использующие такие символы, как `*`, `**`, `+`, `?`, `!` и другие, для сопоставления нескольких имен ветвей или тегов. Если имя содержит любой из этих символов, и требуется буквальное совпадение, необходимо *экранировать* каждый из этих специальных символов с помощью `\`. Дополнительные сведения о шаблонах глобов см. в [разделе AUTOTITLE](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet). ### Пример. Включение ветвей и тегов Шаблоны, определенные в `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`). ```yaml 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-ignore` или `tags-ignore`, рабочий процесс не будет выполняться. Шаблоны, определенные в `branches` и `tags`, применяются для имени ссылки Git. Например, следующий рабочий процесс будет выполняться всякий раз, когда происходит событие `push`, если при этом не происходит событие `push` в: * ветви с именем `mona/octocat` (`refs/heads/mona/octocat`); * ветви, имя которой соответствует `releases/**-alpha`, например `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`); * теге с именем `v2` (`refs/tags/v2`); * теге, имя которого начинается с `v1.`, например `v1.9` (`refs/tags/v1.9`). ```yaml on: push: # Sequence of patterns matched against refs/heads branches-ignore: - 'mona/octocat' - 'releases/**-alpha' # Sequence of patterns matched against refs/tags tags-ignore: - 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`. ```yaml on: push: branches: - 'releases/**' - '!releases/**-alpha' ``` ## `on..` При использовании событий `push` и `pull_request` можно настроить запускаемый рабочий процесс в зависимости от того, какие пути к файлам изменяются. Фильтры путей не оцениваются при отправке тегов. Используйте фильтр `paths`, если требуется включить шаблоны путей к файлам или одновременно включить и исключить их. Используйте фильтр `paths-ignore`, если требуется только исключить шаблоны путей к файлам. Для одного и того же события в рабочем процессе нельзя использовать фильтры `paths` и `paths-ignore` одновременно. Если вы хотите включить и исключить шаблоны путей для одного события, используйте `paths` префикс фильтра с `!` символом, чтобы указать, какие пути следует исключить. > \[!NOTE] > Порядок определения `paths` шаблонов имеет значение: > > * Соответствующий отрицательный шаблон (с префиксом `!`) после положительного совпадения исключает путь. > * Соответствующий положительный шаблон после отрицательного совпадения снова включает путь. Если вы определили и `branches`/`branches-ignore`, и `paths`/`paths-ignore`, рабочий процесс будет запускаться только в случае, если выполнены оба фильтра. Ключевые слова `paths` и `paths-ignore` принимают стандартные маски, в которых для соответствия нескольким именам путей используются подстановочные знаки `*` и `**`. Дополнительные сведения см. в [разделе AUTOTITLE](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet). ### Пример. Включение путей Если хотя бы один путь соответствует шаблону в фильтре `paths`, рабочий процесс запускается. Например, приведенный ниже рабочий процесс будет выполняться при каждой отправке файла JavaScript (`.js`). ```yaml on: push: paths: - '**.js' ``` Не следует использовать фильтрацию пути или ветви, чтобы пропустить выполнение рабочего процесса, если рабочий процесс необходим для передачи перед слиянием. Дополнительные сведения см. в разделе \[AUTOTITLE и [Пропуск запусков рабочих процессов](/ru/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/skip-workflow-runs)]\(/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging). Если рабочий процесс пропускается из-за фильтрации путей, [фильтрации](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore) ветвей или [сообщения](/ru/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/skip-workflow-runs) фиксации, то проверки, связанные с этим рабочим процессом, останутся в состоянии "Ожидание". Запрос на включение внесенных изменений, требующий успешной проверки, будет заблокирован при слиянии. ### Пример. Исключение путей Если все имена путей соответствуют шаблонам в `paths-ignore`, рабочий процесс не запускается. Если хотя бы одно имя пути не соответствует шаблонам в `paths-ignore`, рабочий процесс запускается. Рабочий процесс с приведенным ниже фильтром пути будет выполняться только при событиях `push` с по крайней мере одним файлом за пределами каталога `docs` в корне репозитория. ```yaml 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`, не запустит его. ```yaml on: push: paths: - 'sub-project/**' - '!sub-project/docs/**' ``` ### Сравнение различий в GIT Фильтр определяет, должен ли запускаться рабочий процесс, оценивая измененные файлы и проверяя их по списку `paths-ignore` или `paths`. Если измененных файлов нет, рабочий процесс не запускается. GitHub Создает список измененных файлов с помощью двухточийных диффов для отправки и трехточийных диффов для запросов на вытягивание: * **Запросы на вытягивание**. Различия с тремя точками — это сравнение последней версией тематической ветки с фиксацией, в которой тематическая ветка была в последний раз синхронизирована с основной ветвью. * **Отправки в существующие ветви**. Различие с двумя точками — это сравнение головных и базовых значений SHA непосредственно друг с другом. * **Отправки в новые ветви**. Различие с двумя точками в сравнении с родителем предка самой глубокой отправленной фиксации. В некоторых ситуациях применяются ограничения, GitHub Actions которые изменяют способ выполнения фильтруемых рабочих процессов: * Если push-отправка содержит более 1000 фиксаций, рабочий процесс **всегда** будет выполняться. * При создании времени ожидания диффа рабочий процесс **всегда** будет выполняться. * Если созданный дифф содержит более 3000 файлов, а файлы, соответствующие фильтрам рабочих процессов, не находятся в первом 3000, возвращаемом фильтром, рабочий процесс **не** будет выполняться. Если вы наблюдаете это поведение, может потребоваться сделать фильтры более конкретными или изменить способ работы с push-отправками и запросами на вытягивание для создания более простых диффов. Дополнительные сведения см. в разделе [Филиалы](/ru/enterprise-server@3.22/pull-requests/reference/branches). ## `on.schedule` С помощью `on.schedule` можно определить расписание рабочих процессов. Используйте [синтаксис POSIX cron](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07) для планирования рабочих процессов в определённое время. По умолчанию запланированные рабочие процессы выполняются в формате UTC. При необходимости можно указать часовой пояс с помощью [строки часового пояса IANA](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) для. Запланированные рабочие процессы выполняются в последней фиксации на ветвь по умолчанию. Самый короткий интервал, с которым можно запускать запланированные рабочие процессы — 5 минут. > \[!NOTE] > Для расписаний, установленных `timezone` на часовой пояс, соблюдающий летнее время (DST), во время переходов на летнее время расписание в пропущенные часы перемещаются до следующего действительного времени. Например, расписание на 2:30 ночи переносится на 3:00 ночи. Синтаксис Cron содержит пять полей, разделенных пробелом, где каждое поле представляет единицу времени. ```text ┌───────────── minute (0 - 59) │ ┌───────────── hour (0 - 23) │ │ ┌───────────── day of the month (1 - 31) │ │ │ ┌───────────── month (1 - 12 or JAN-DEC) │ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT) │ │ │ │ │ * * * * * ``` Эти операторы можно использовать в любом из пяти полей: | Operator | Description | Пример | | ------------------------------------------------------------------------------------------------------ | --------------------------- | ------ | | \* | Любое значение | | | `15 * * * *` запускается в каждую 15-ю минуту каждого часа каждого дня. | | | | , | Разделитель списка значений | | | `2,10 4,5 * * *` запускается во 2-ю и 10-ю минуты каждого 4-го и 5-го часов каждого дня. | | | | - | Диапазон значений | | | `30 4-6 * * *` запускается в 30-ю минуту каждого 4-го, 5-го и 6-го часов. | | | | / | Значения шага | | | `20/15 * * * *` запускается каждые 15 минут с 20-й по 59-ю минуту (в каждую 20-ю, 35-ю и 50-ю минуты). | | | В этом примере рабочий процесс запускается в 5:30 утра в часовом поясе America/New\_York каждый понедельник по пятницу: ```yaml on: schedule: - cron: '30 5 * * 1-5' timezone: "America/New_York" ``` Один рабочий процесс может запускаться несколькими событиями `schedule`. Доступ к событию `schedule` , активировав рабочему процессу через `github.event.schedule` контекст. В этом примере рабочий процесс запускается в 5:30 UTC каждый понедельник-четверг и 17:30 UTC во вторник и четверг, но пропускает `Not on Monday or Wednesday` шаг в понедельник и среду. ```yaml on: schedule: - cron: '30 5 * * 1,3' - cron: '30 5,17 * * 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" ``` Дополнительные сведения о событиях см. в `schedule` разделе [События, инициирующие рабочие процессы](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule). ## `on.workflow_call` Используйте `on.workflow_call` для определения входных и выходных данных для многократно используемого рабочего процесса. Вы также можете сопоставить секреты, доступные для вызываемого рабочего процесса. Дополнительные сведения о повторно используемых рабочих процессах см. в разделе [Повторное использование рабочих процессов](/ru/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows). ## `on.workflow_call.inputs` При использовании ключевого слова `workflow_call` можно дополнительно указать входные данные, передаваемые вызываемому рабочему процессу из вызывающего рабочего процесса. Дополнительные сведения о ключевом слове `workflow_call` см. в разделе [События, инициирующие рабочие процессы](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_call). Помимо доступных стандартных входных параметров `on.workflow_call.inputs` требует параметр `type`. Дополнительные сведения см. в разделе [`on.workflow_call.inputs..type`](#onworkflow_callinputsinput_idtype). Если параметр `default` не задан, значение по умолчанию для входных данных — `false` для логического значения, `0` для числа и `""` для строки. В вызываемом рабочем процессе можно использовать контекст `inputs` для ссылки на входные данные. Дополнительные сведения см. в разделе [Справочник по контекстам](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#inputs-context). Если вызывающий рабочий процесс передает входные данные, которые не указаны в вызываемом рабочем процессе, это приведет к ошибке. ### Пример `on.workflow_call.inputs` ```yaml 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 }} ``` Дополнительные сведения см. в разделе [Повторное использование рабочих процессов](/ru/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows). ## `on.workflow_call.inputs..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` ```yaml 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..outputs`](#jobsjob_idoutputs). Дополнительные сведения см. в разделе [Повторное использование рабочих процессов](/ru/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows). ## `on.workflow_call.secrets` Карта секретов, которые можно использовать в вызываемом рабочем процессе. В вызываемом рабочем процессе можно использовать контекст `secrets` для ссылки на секрет. > \[!NOTE] > Если секрет передается в вложенный повторно используемый рабочий процесс, необходимо использовать [`jobs..secrets`](#jobsjob_idsecrets) еще раз для передачи секрета. Дополнительные сведения см. в разделе [Повторное использование рабочих процессов](/ru/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows#passing-secrets-to-nested-workflows). Если вызывающий рабочий процесс передает секрет, который не указан в вызываемом рабочем процессе, это приведет к ошибке. ### Пример `on.workflow_call.secrets` ```yaml 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.` Строковый идентификатор, связанный с секретом. ## `on.workflow_call.secrets..required` Логическое значение, указывающее, должен ли быть предоставлен секрет. ## `on.workflow_run.` При использовании события `workflow_run` можно указать, в каких ветвях должен выполняться запускающий рабочий процесс, чтобы активировать ваш рабочий процесс. В фильтрах `branches` и `branches-ignore` можно использовать стандартные маски с такими символами, как `*`, `**`, `+`, `?`, `!` и другие, для сопоставления нескольких имен ветвей. Если имя содержит любой из этих символов, и требуется буквальное совпадение, необходимо *экранировать* каждый из этих специальных символов с помощью `\`. Дополнительные сведения о шаблонах глобов см. в [разделе AUTOTITLE](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet). Например, рабочий процесс со следующим триггером будет выполняться, только если рабочий процесс с именем `Build` выполняется в ветви, имя которой начинается с `releases/`. ```yaml on: workflow_run: workflows: ["Build"] types: [requested] branches: - 'releases/**' ``` Рабочий процесс со следующим триггером будет выполняться, только если рабочий процесс с именем `Build` выполняется в ветви с именем отличным от `canary`. ```yaml 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`. ```yaml on: workflow_run: workflows: ["Build"] types: [requested] branches: - 'releases/**' - '!releases/**-alpha' ``` ## `on.workflow_dispatch` При использовании события `workflow_dispatch` можно дополнительно указать входные данные, передаваемые рабочему процессу. Этот триггер получает события только в том случае, если файл рабочего процесса находится на ветвь по умолчанию. ## `on.workflow_dispatch.inputs` Активированный рабочий процесс получает входные данные в контексте `inputs`. Дополнительные сведения см. в разделе ["Контексты](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#inputs-context)". > \[!NOTE] > > * Рабочий процесс также получит входные данные в контексте `github.event.inputs` . Информация в контексте `inputs` и в контексте `github.event.inputs` идентична, за исключением того, что контекст `inputs` сохраняет логические значения в исходном формате логических значений, не преобразовывая их в строки. Тип `choice` разрешается в строку и является одним вариантом выбора. > * Максимальное количество свойств верхнего уровня для `inputs` — 10 . > * Максимальная полезная нагрузка составляет `inputs` 65 535 символов. ### Пример `on.workflow_dispatch.inputs` ```yaml 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..required` Логическое значение, указывающее, нужно ли предоставлять входные данные. ## `on.workflow_dispatch.inputs..type` Значение этого параметра — строка, указывающая тип входных данных. Это должно быть одно из следующих: `boolean`, `choice``number``environment` или .`string` ## `permissions` `permissions` можно использовать для изменения разрешений по умолчанию, предоставленных `GITHUB_TOKEN`, при необходимости добавляя или удаляя права доступа, чтобы разрешить только минимальный требуемый доступ. Дополнительные сведения см. в разделе [Использование GITHUB\_TOKEN для проверки подлинности в рабочих процессах](/ru/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token). `permissions` можно использовать в качестве ключа верхнего уровня для применения ко всем заданиям в рабочем процессе или в конкретных заданиях. При добавлении ключа `permissions` в конкретном задании указанные права доступа получают все действия и команды выполнения в этом задании, использующие `GITHUB_TOKEN`. Дополнительные сведения см. в разделе [`jobs..permissions`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idpermissions). Владельцы организации или предприятия могут ограничить доступ на запись на `GITHUB_TOKEN` уровне репозитория. Дополнительные сведения см. в разделе [Отключение или ограничение GitHub Actions для вашей организации](/ru/enterprise-server@3.22/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization) и [](/ru/enterprise-server@3.22/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#enforcing-a-policy-for-workflow-permissions-in-your-enterprise). При активации [`pull_request_target`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_target) рабочего процесса событием `GITHUB_TOKEN` предоставляется разрешение на чтение и запись репозитория, даже если он активируется из общедоступной вилки. Дополнительные сведения см. в разделе [События, инициирующие рабочие процессы](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_target). Для каждого из доступных разрешений, показанных в таблице ниже, можно назначить один из уровней доступа: `read` (если применимо), `write`или `none`. `write` включает в себя `read`. Если указать доступ для любого из этих разрешений, то для всех этих разрешений задано `none`значение . Доступные разрешения и подробные сведения о том, что позволяет выполнять действие: | Разрешение | Разрешает действие с помощью `GITHUB_TOKEN` | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `actions` | Работа с GitHub Actions. Например, `actions: write` позволяет действию отменить выполнение рабочего процесса. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions). | | | | | | | | `checks` | Работа с проверками запусков и контрольных наборов. Например, `checks: write` позволяет действию создать выполнение проверки. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks). | | | | | `contents` | Работа с содержимым репозитория. Например, `contents: read` позволяет действию перечислять фиксации и `contents: write` позволяет действию создавать выпуск. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents). | | `deployments` | Работа с развертываниями. Например, `deployments: write` позволяет действию создать новое развертывание. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments). | | `discussions` | Работа с обсуждениями GitHub. Например, `discussions: write` позволяет действию закрыть или удалить обсуждение. Дополнительные сведения см. в разделе [Использование API GraphQL для обсуждений](/ru/enterprise-server@3.22/graphql/guides/using-the-graphql-api-for-discussions). | | | | | `issues` | Работа с проблемами. Например, `issues: write` позволяет действию добавить комментарий к проблеме. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues). | | `packages` | Работа с пакетами GitHub. Например, `packages: write` позволяет действию отправлять и публиковать пакеты в пакетах GitHub. Дополнительные сведения см. в разделе [Сведения о разрешениях для пакетов GitHub](/ru/enterprise-server@3.22/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries). | | `pages` | Работа с GitHub Pages. Например, `pages: write` позволяет действию запрашивать сборку GitHub Pages. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages). | | `pull-requests` | Работа с запросами на вытягивание. Например, `pull-requests: write` позволяет действию добавить метку в запрос на вытягивание. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests). | | `security-events` | Работа с оповещениями проверки кода GitHub. Например, `security-events: read` позволяет действию выводить список оповещений сканирования кода для репозитория и `security-events: write` позволяет действию обновлять состояние оповещений сканирования кода. Для получения дополнительной информации [смотрите раздел разрешений репозитория для раздела «Уведомления о сканировании кода».](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts)

| | Уведомления о сканировании Dependabot и секретного сканирования нельзя читать с этим разрешением и требуют приложения GitHub или personal access token. Для получения дополнительной информации см. [раздел «Разрешения репозитория для «Dependabot alerts](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts) » и « [Секретные оповещения о сканировании»](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) в разделе «Разрешения, необходимые для приложений GitHub». | | | `statuses` | Работа с состояниями фиксации. Например, `statuses:read` позволяет действию выводить список состояний фиксации для указанной ссылки. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses). | | | | ### Определение доступа для `GITHUB_TOKEN` областей Вы можете определить доступ, который `GITHUB_TOKEN` будет разрешен, указав `read`или `write``none` как значение доступных разрешений в `permissions` ключе. ```yaml 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 security-events: read|write|none statuses: read|write|none ``` Если указать доступ для любого из этих разрешений, то для всех этих разрешений задано `none`значение . Для определения одного из `read-all``write-all` доступных разрешений можно использовать следующий синтаксис: ```yaml permissions: read-all ``` ```yaml permissions: write-all ``` Для отключения разрешений для всех доступных разрешений можно использовать следующий синтаксис: ```yaml permissions: {} ``` #### Изменение разрешений в вилку репозитория С помощью ключа `permissions` можно добавлять и удалять разрешения на чтение для разветвленных репозиториев, но обычно предоставить доступ на запись нельзя. Исключение из этого поведения — когда администратор-пользователь выбрал **токены «Отправить токены записи в рабочие процессы» из опции pull** requests в GitHub Actions настройках. Дополнительные сведения см. в разделе [Управление настройками GitHub Actions для репозитория](/ru/enterprise-server@3.22/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories). ### Как вычисляются разрешения для задания рабочего процесса Изначально в качестве разрешений для `GITHUB_TOKEN` задаются параметры по умолчанию для предприятия, организации или репозитория. Если на любом из этих уровней по умолчанию заданы ограниченные разрешения, они будут применяться к соответствующим репозиториям. Например, если выбрать в качестве значения по умолчанию на уровне организации ограниченные разрешения, все репозитории в этой организации будут использовать в качестве значения по умолчанию ограниченные разрешения. Затем разрешения корректируются на основе любой конфигурации в файле рабочего процесса: сначала на уровне рабочего процесса, а затем на уровне задания. Наконец, если рабочий процесс был запущен событием pull request, отличным `pull_request_target` от форкированного репозитория, и **токены Send write to workflows из настройки pull** requests не выбраны, права на запись изменяются на только чтение. ### `GITHUB_TOKEN` Настройка разрешений для всех заданий в рабочем процессе Можно указать `permissions` на верхнем уровне рабочего процесса, чтобы параметр применялось ко всем заданиям в рабочем процессе. #### Пример. Настройка `GITHUB_TOKEN` разрешений для всего рабочего процесса В этом примере показаны разрешения, заданные для `GITHUB_TOKEN`, которые будут применены ко всем заданиям в рабочем процессе. Всем разрешениям предоставляется доступ на чтение. ```yaml name: "My workflow" on: [ push ] permissions: read-all jobs: ... ``` ### `permissions` Использование ключа для вилированных репозиториев Ключ можно использовать `permissions` для добавления и удаления `read` разрешений для вилированных репозиториев, но обычно невозможно предоставить `write` доступ. Исключение из этого поведения — когда администратор-пользователь выбрал **токены «Отправить токены записи в рабочие процессы» из опции pull** requests в GitHub Actions настройках. Дополнительные сведения см. в разделе [Управление настройками GitHub Actions для репозитория](/ru/enterprise-server@3.22/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories). ### Права на запуски рабочих процессов, вызываемые Dependabot Рабочие процессы запускаются запросами Dependabot на вытягивание, как если бы они были из вилированного репозитория, поэтому используйте только `GITHUB_TOKEN`для чтения. Этот рабочий процесс не может получить доступ к секретам. Сведения о стратегиях защиты этих рабочих процессов см. в разделе [Справочник по безопасному использованию](/ru/enterprise-server@3.22/actions/reference/security/secure-use). ## `env` Переменные `map` , доступные для шагов всех заданий в рабочем процессе. Можно также задать переменные, доступные только для шагов одного задания или на одном шаге. Дополнительные сведения см. в разделах [`jobs..env`](#jobsjob_idenv) и [`jobs..steps[*].env`](#jobsjob_idstepsenv). Переменные на схеме `env` не могут быть определены с точки зрения других переменных на карте. При определении нескольких переменных среды с тем же именем GitHub использует самую конкретную переменную. Например, переменная среды, определенная на шаге, переопределяет переменные задания и среды рабочего процесса с тем же именем, а шаг выполняется. Переменная среды, определенная для задания, переопределяет переменную рабочего процесса с тем же именем, а задание выполняется. ### Пример `env` ```yaml env: SERVER: production ``` ## `defaults` Используйте `defaults` для создания `map` с параметрами по умолчанию, которые будут применяться ко всем заданиям в рабочем процессе. Можно также указать параметры по умолчанию, доступные только для задания. Дополнительные сведения см. в разделе [`jobs..defaults`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaults). Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе. ## `defaults.run` Можно использовать `defaults.run` для указания параметров по умолчанию `shell` и `working-directory` для всех этапов [`run`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsrun) в рабочем процессе. Можно также указать параметры по умолчанию для `run`, доступные только для задания. Дополнительные сведения см. в разделе [`jobs..defaults.run`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrun). В этом ключевом слове нельзя использовать контексты или выражения. Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе. ### Пример. Указание оболочки по умолчанию и рабочего каталога ```yaml defaults: run: shell: bash working-directory: ./scripts ``` ## `defaults.run.shell` Используется `shell` для определения `shell` шага. Это ключевое слово может ссылаться на несколько контекстов. Дополнительные сведения см. в разделе ["Контексты](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability)". | Поддерживаемая платформа | `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` шага. Это ключевое слово может ссылаться на несколько контекстов. Дополнительные сведения см. в разделе ["Контексты](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability)". > \[!TIP] > Перед запуском оболочки убедитесь, что `working-directory` назначаемая функция существует в средстве выполнения. > Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе. ## `concurrency` Используйте `concurrency`, чтобы одновременно могли выполняться только одно задание или один процесс с использованием той же группы параллелизма. Группа параллелизма может представлять собой любую строку или выражение. Выражение может использовать `github`[](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#github-context)только контекст и контексты. Дополнительные сведения о выражениях см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions). Также можно задать `concurrency` на уровне задания. Дополнительные сведения см. в разделе [`jobs..concurrency`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idconcurrency). Это означает, что в любое время в группе параллелизма может быть не более одного запущенного и одного ожидающего задания. Если параллельное задание или рабочий процесс добавлены в очередь и выполняется другое задание или рабочий процесс, использующие ту же группу параллелизма в репозитории, то находящиеся в очереди задание или рабочий процесс будут `pending`. Любое существующее `pending` задание или рабочий процесс в той же группе параллелизма, если она существует, будет отменена, а новое задание или рабочий процесс в очереди будет выполняться. Чтобы также отменить задание или рабочий процесс, которые сейчас выполняются в той же группе параллелизма, укажите `cancel-in-progress: true`. Чтобы условно отменить выполняемые в настоящее время задания или рабочие процессы в той же группе параллелизма, можно указать `cancel-in-progress` как выражение с любым из контекстов разрешенного выражения. > \[!NOTE] > > * Имя группы параллелизма не учитывает регистр. Например, `prod` и `Prod` будет рассматриваться как та же группа параллелизма. > * Задания или рабочие процессы в одной и той же группе параллелизма обрабатываются в порядке «первый вошёл — первый ушёл» (FIFO) в зависимости от времени ожидания группы параллелизма, а не по времени отправки каждого рабочего процесса. Поскольку фактическое время начала работы или запуска может различаться, заказ не гарантируется. ### Пример. Использование параллелизма и поведения по умолчанию По умолчанию GitHub Actions режим позволяет выполнять несколько заданий или рабочих процессов одновременно. Ключевое `concurrency` слово позволяет управлять параллелизмом выполнения рабочих процессов. Например, ключевое `concurrency` слово можно использовать сразу после определения условий триггера, чтобы ограничить параллелизм всего рабочего процесса для определенной ветви: ```yaml on: push: branches: - main concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` Кроме того, можно ограничить параллелизм заданий в рабочем процессе с помощью `concurrency` ключевого слова на уровне задания: ```yaml 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` группе параллелизма, которые уже выполняются, будут отменены. ```yaml jobs: job-1: runs-on: ubuntu-latest concurrency: group: staging_environment cancel-in-progress: true ``` Кроме того, использование динамического выражения, например `concurrency: ci-${{ github.ref }}` в рабочем процессе, означает, что рабочий процесс или задание будет частью группы `ci-` параллелизма, за которой следует ссылка на ветвь или тег, активировавший рабочий процесс. В этом примере, если новая фиксация отправляется в основную ветвь, пока предыдущий запуск по-прежнему выполняется, предыдущий запуск будет отменен, а новый будет запущен: ```yaml on: push: branches: - main concurrency: group: ci-${{ github.ref }} cancel-in-progress: true ``` ### Пример. Использование параллелизма для отмены любого выполняющегося задания или запуска Чтобы использовать параллелизм для отмены любой текущей задачи или запускаGitHub Actions, вы можете использовать `concurrency` ключ с опцией`true`:`cancel-in-progress` ```yaml concurrency: group: ${{ github.ref }} cancel-in-progress: true ``` Обратите внимание, что в этом примере, без определения конкретной группы параллелизма, GitHub Actions\_будет отменён любой\_ текущий запуск задания или рабочего процесса. ### Пример. Использование резервного значения Если вы создаете имя группы со свойством, определенным только для определенных событий, можно использовать резервное значение. Например, `github.head_ref` определяется только для событий `pull_request`. Если рабочий процесс реагирует на другие события в дополнение к событиям `pull_request`, необходимо предоставить резервное значение, чтобы избежать синтаксической ошибки. Следующая группа параллелизма отменяет выполняемые задания или запуски только в событиях `pull_request`. Если параметр `github.head_ref` не определен, группа параллелизма перейдет к идентификатору запуска, который будет гарантированно заданным и уникальным. ```yaml concurrency: group: ${{ github.head_ref || github.run_id }} cancel-in-progress: true ``` ### Пример. Отмена только выполняемых заданий или запусков для текущего рабочего процесса При наличии нескольких рабочих процессов в одном репозитории имена групп параллелизма должны быть уникальными в разных рабочих процессах, чтобы избежать отмены выполняемых заданий или запусков из других рабочих процессов. В противном случае все ранее выполняемые или ожидающие задания будут отменены независимо от рабочего процесса. Чтобы отменить только выполняемые запуски для одного рабочего процесса, можно использовать свойство `github.workflow` для создания группы параллелизма: ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` ### Пример. Отмена только выполняемых заданий в определенных ветвях Если вы хотите отменить выполняемые задания в определенных ветвях, но не на других, можно использовать условные выражения с `cancel-in-progress`. Например, это можно сделать, если вы хотите отменить выполняемые задания в ветвях разработки, но не в ветвях выпуска. Чтобы отменить выполнение только выполняемых запусков одного рабочего процесса, если он не запущен в ветви выпуска, можно задать `cancel-in-progress` выражение, аналогичное следующему: ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: ${{ !contains(github.ref, 'release/')}} ``` В этом примере несколько push-уведомлений в `release/1.2.3` ветвь не отменяют выполняемые запуски. Отправка в другую ветвь, например `main`, отменяет выполняемые запуски. ## `jobs` Запуск рабочего процесса состоит из одного или нескольких `jobs`, которые по умолчанию выполняются параллельно. Для последовательного выполнения заданий можно определить зависимости в других заданиях с помощью ключевого слова `jobs..needs`. Каждое задание выполняется в среде средства выполнения тестов, указанной в параметре `runs-on`. Вы можете выполнять неограниченное количество заданий, если вы не превышаете лимиты по использованию рабочих процессов. Для получения дополнительной информации см. [Выставление счетов и использование](/ru/enterprise-server@3.22/actions/concepts/billing-and-usage) для GitHub-hosted runners и [Ограничения действий](/ru/enterprise-server@3.22/actions/reference/limits) для самостоятельных ограничений использования бегунов. Если вам нужно найти уникальный идентификатор задания, выполняющегося в рабочем процессе, можно использовать GitHub API. Дополнительные сведения см. в разделе [REST API endpoints для GitHub Actions](/ru/enterprise-server@3.22/rest/actions#workflow-jobs). ## `jobs.` Используйте `jobs.`, чтобы назначить заданию уникальный идентификатор. Ключ `job_id` представляет собой строку, а значение ключа представляет собой карту данных конфигурации задания. Необходимо заменить `` строкой, уникальной для объекта `jobs`. `` должен начинаться с буквы или `_` и может включать только буквенно-цифровые символы `-` или `_`. ### Пример. Создание заданий В этом примере были созданы два задания, и их `job_id` равны `my_first_job` и `my_second_job`. ```yaml jobs: my_first_job: name: My first job my_second_job: name: My second job ``` ## `jobs..name` Используйте `jobs..name` для присвоения имени заданию, которое отображается в пользовательском интерфейсе GitHub. ## `jobs..permissions` Для определенного задания `jobs..permissions` можно использовать для изменения разрешений по умолчанию, предоставленных `GITHUB_TOKEN`, при необходимости добавляя или удаляя права доступа, чтобы разрешить только минимальный требуемый доступ. Дополнительные сведения см. в разделе [Использование GITHUB\_TOKEN для проверки подлинности в рабочих процессах](/ru/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token). Указав разрешение в определении задания, при необходимости можно настроить для каждого задания другой набор разрешений для `GITHUB_TOKEN`. Кроме того, можно указать разрешения для всех заданий в рабочем процессе. Сведения об определении разрешений на уровне рабочего процесса см. в разделе [`permissions`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#permissions). Для каждого из доступных разрешений, показанных в таблице ниже, можно назначить один из уровней доступа: `read` (если применимо), `write`или `none`. `write` включает в себя `read`. Если указать доступ для любого из этих разрешений, то для всех этих разрешений задано `none`значение . Доступные разрешения и подробные сведения о том, что позволяет выполнять действие: | Разрешение | Разрешает действие с помощью `GITHUB_TOKEN` | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `actions` | Работа с GitHub Actions. Например, `actions: write` позволяет действию отменить выполнение рабочего процесса. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions). | | | | | | | | `checks` | Работа с проверками запусков и контрольных наборов. Например, `checks: write` позволяет действию создать выполнение проверки. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks). | | | | | `contents` | Работа с содержимым репозитория. Например, `contents: read` позволяет действию перечислять фиксации и `contents: write` позволяет действию создавать выпуск. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents). | | `deployments` | Работа с развертываниями. Например, `deployments: write` позволяет действию создать новое развертывание. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments). | | `discussions` | Работа с обсуждениями GitHub. Например, `discussions: write` позволяет действию закрыть или удалить обсуждение. Дополнительные сведения см. в разделе [Использование API GraphQL для обсуждений](/ru/enterprise-server@3.22/graphql/guides/using-the-graphql-api-for-discussions). | | | | | `issues` | Работа с проблемами. Например, `issues: write` позволяет действию добавить комментарий к проблеме. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues). | | `packages` | Работа с пакетами GitHub. Например, `packages: write` позволяет действию отправлять и публиковать пакеты в пакетах GitHub. Дополнительные сведения см. в разделе [Сведения о разрешениях для пакетов GitHub](/ru/enterprise-server@3.22/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries). | | `pages` | Работа с GitHub Pages. Например, `pages: write` позволяет действию запрашивать сборку GitHub Pages. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages). | | `pull-requests` | Работа с запросами на вытягивание. Например, `pull-requests: write` позволяет действию добавить метку в запрос на вытягивание. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests). | | `security-events` | Работа с оповещениями проверки кода GitHub. Например, `security-events: read` позволяет действию выводить список оповещений сканирования кода для репозитория и `security-events: write` позволяет действию обновлять состояние оповещений сканирования кода. Для получения дополнительной информации [смотрите раздел разрешений репозитория для раздела «Уведомления о сканировании кода».](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts)

| | Уведомления о сканировании Dependabot и секретного сканирования нельзя читать с этим разрешением и требуют приложения GitHub или personal access token. Для получения дополнительной информации см. [раздел «Разрешения репозитория для «Dependabot alerts](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts) » и « [Секретные оповещения о сканировании»](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) в разделе «Разрешения, необходимые для приложений GitHub». | | | `statuses` | Работа с состояниями фиксации. Например, `statuses:read` позволяет действию выводить список состояний фиксации для указанной ссылки. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses). | | | | ### Определение доступа для `GITHUB_TOKEN` областей Вы можете определить доступ, который `GITHUB_TOKEN` будет разрешен, указав `read`или `write``none` как значение доступных разрешений в `permissions` ключе. ```yaml 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 security-events: read|write|none statuses: read|write|none ``` Если указать доступ для любого из этих разрешений, то для всех этих разрешений задано `none`значение . Для определения одного из `read-all``write-all` доступных разрешений можно использовать следующий синтаксис: ```yaml permissions: read-all ``` ```yaml permissions: write-all ``` Для отключения разрешений для всех доступных разрешений можно использовать следующий синтаксис: ```yaml permissions: {} ``` #### Изменение разрешений в вилку репозитория С помощью ключа `permissions` можно добавлять и удалять разрешения на чтение для разветвленных репозиториев, но обычно предоставить доступ на запись нельзя. Исключение из этого поведения — когда администратор-пользователь выбрал **токены «Отправить токены записи в рабочие процессы» из опции pull** requests в GitHub Actions настройках. Дополнительные сведения см. в разделе [Управление настройками GitHub Actions для репозитория](/ru/enterprise-server@3.22/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories). #### Пример. Настройка `GITHUB_TOKEN` разрешений для одного задания в рабочем процессе В этом примере показаны разрешения, заданные для задания `GITHUB_TOKEN`, которое будет применяться только к заданию с именем `stale`. Доступ на запись предоставляется для `issues` разрешений и `pull-requests` разрешений. Все остальные разрешения не будут иметь доступа. ```yaml jobs: stale: runs-on: ubuntu-latest permissions: issues: write pull-requests: write steps: - uses: actions/stale@v10 ``` ## `jobs..needs` Используйте `jobs..needs` для определения всех заданий, которые должны быть успешно завершены перед выполнением этого задания. Это может быть строка или массив строк. Если задание завершается ошибкой или пропускается, все задания, необходимые для него, пропускаются, если задания не используют условное выражение, которое приводит к продолжению задания. Если выполнение содержит ряд заданий, которые нуждаются друг в другом, сбой или пропуск применяется ко всем заданиям в цепочке зависимостей из точки сбоя или пропускания. Если вы хотите выполнить задание, даже если задание зависит от не удалось, используйте условное `always()` выражение в `jobs..if`. ### Пример. Необходимо успешное выполнение зависимых заданий ```yaml jobs: job1: job2: needs: job1 job3: needs: [job1, job2] ``` В этом примере задание `job1` должно успешно завершить работу перед началом задания `job2`, а задание `job3` ожидает завершения заданий `job1` и `job2`. Задания в этом примере выполняются последовательно: 1. `job1` 2. `job2` 3. `job3` ### Пример. Успешное выполнение зависимых заданий не требуется ```yaml jobs: job1: job2: needs: job1 job3: if: ${{ always() }} needs: [job1, job2] ``` В этом примере в задании `job3` используется условное выражение `always()`, чтобы оно всегда выполнялось после завершения выполнения заданий `job1` и `job2`, независимо от того, завершились ли они успешно. Дополнительные сведения см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions#status-check-functions). ## `jobs..if` Условное выражение `jobs..if` можно использовать для предотвращения выполнения задания, если условие не выполняется. Для создания условного выражения можно использовать любой поддерживаемый контекст и любое выражение. Дополнительные сведения о том, какие контексты поддерживаются в этом ключе, см. в разделе [Справочник по контекстам](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability). > \[!NOTE] > Условие `jobs..if` вычисляется перед [`jobs..strategy.matrix`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategymatrix) применением. При использовании выражений в условном `if` режиме можно, при необходимости, опустить синтаксис выражения `${{ }}`, так как GitHub Actions автоматически вычисляет условное `if` выражение как выражение. Однако это исключение не применяется везде. Всегда следует использовать синтаксис выражения `${{ }}`концевого выражения %} или экранировать с `''`, `""`либо `()` когда выражение начинается с `!`, так как `!` зарезервировано нотация в формате YAML. Например: {% raw %} ```yaml if: ${{ ! startsWith(github.ref, 'refs/tags/') }} ``` Для получения дополнительной информации см. [Оценка выражений в рабочих процессах и действиях](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions). ### Пример. Выполнение задания только для определенного репозитория В этом примере используется `if` для управления выполнением задания `production-deploy`. Оно будет выполняться только в том случае, если репозиторий имеет имя `octo-repo-prod` и находится в организации `octo-org`. В противном случае задание будет отмечено как *пропущенное*. ```yaml copy name: example-workflow on: [push] jobs: production-deploy: if: github.repository == 'octo-org/octo-repo-prod' runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v7 with: node-version: '14' - run: npm install -g bats ``` ## `jobs..runs-on` Используйте `jobs..runs-on` для определения типа компьютера, на котором будет запускаться задание. * Машина назначения может быть [бегуном](#choosing-self-hosted-runners). * Вы можете нацеливать бегуна на основе меток, назначенных им, или их членства в группах или сочетания этих. * Вы можете предоставить следующие возможности `runs-on` : * Одна строка * Одна переменная, содержащая строку * Массив строк, переменных, содержащих строки, или сочетание обоих * `key: value` Пара с помощью клавиш или `group` ключей `labels` * При указании массива строк или переменных рабочий процесс будет выполняться на любом средстве выполнения, который соответствует всем указанным `runs-on` значениям. Например, здесь задание будет выполняться только на локальном runner с метками `linux`и`x64``gpu`: ```yaml runs-on: [self-hosted, linux, x64, gpu] ``` Дополнительные сведения см. в разделе ["Выбор локальных](#choosing-self-hosted-runners) средств выполнения". * Строки и переменные можно смешивать в массиве. Например: ```yaml on: workflow_dispatch: inputs: chosen-os: required: true type: choice options: - Ubuntu - macOS jobs: test: runs-on: [self-hosted, "${{ inputs.chosen-os }}"] steps: - run: echo Hello world! ``` * Если необходимо запустить рабочий процесс на нескольких компьютерах, используйте [`jobs..strategy`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategy). > \[!NOTE] > Кавычки не требуются вокруг простых строк, таких `self-hosted`как , но они необходимы для выражений вроде`"${{ inputs.chosen-os }}"` . ### Выбор GitHubведущих бегунов > \[!NOTE] > GitHub Enterprise Serverразмещенные в данный момент средства выполнения не поддерживаются в GitHub. ### Выбор локальных средств выполнения тестов Чтобы указать локальное средство выполнения тестов для задания, настройте `runs-on` в файле рабочего процесса, используя метки локального средства выполнения тестов. У локальных модулей выполнения может быть `self-hosted` метка. При настройке локального runner по умолчанию мы будем включать метку `self-hosted`. Вы можете передать `--no-default-labels` флаг, чтобы предотвратить применение локальной метки. Метки можно использовать для создания параметров целевого назначения для средств выполнения, таких как операционная система или архитектура, мы рекомендуем предоставить массив меток, начинающихся с `self-hosted` (это должно быть указано сначала), а затем включить дополнительные метки по мере необходимости. При указании массива меток задания будут помещены в очередь в средства выполнения тестов, которые имеют все указанные метки. > \[!NOTE] Actions Runner Controller не поддерживает эту `self-hosted` метку. #### Пример: использование меток для выбора средства выполнения тестов ```yaml runs-on: [self-hosted, linux] ``` Дополнительные сведения см. в разделе \[AUTOTITLE и [Локальные средства выполнения тестов](/ru/enterprise-server@3.22/actions/concepts/runners/self-hosted-runners)]\(/actions/how-tos/manage-runners/self-hosted-runners/use-in-a-workflow). ### Выбор бегуна в группе Вы можете использовать `runs-on` для целевых групп runner, чтобы задание выполнялось на любом средстве выполнения, являющегося членом этой группы. Для более детального управления можно также объединить группы runner с метками. #### Пример. Использование групп для управления выполнением заданий В этом примере бегунки были добавлены в группу под названием `build-runners`. Ключ `runs-on` отправляет задание любому доступному `build-runners` средству выполнения в группе: ```yaml name: learn-github-actions on: [push] jobs: check-bats-version: runs-on: group: build-runners steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v7 with: node-version: '14' - run: npm install -g bats - run: bats -v ``` #### Пример. Объединение групп и меток При сочетании групп и меток средство выполнения должно соответствовать обоим требованиям, чтобы иметь право на выполнение задания. В этом примере `runs-on` ключ объединяется `group` так `labels` , что задание направляется к любому доступному бегущему в группе, который также имеет совпадающую метку: ```yaml name: learn-github-actions on: [push] jobs: check-bats-version: runs-on: group: ubuntu-runners labels: ubuntu-24.04-16core steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v7 with: node-version: '14' - run: npm install -g bats - run: bats -v ``` #### Пример: использование префиксов для различения групп runner Например, если у вас есть группа runner с именем `my-group` в организации и другая с именем `my-group` в организации, вы можете обновить файл рабочего процесса, чтобы использовать `org/my-group` или `ent/my-group` различать их. Использование среды `org/`: ```yaml runs-on: group: org/my-group labels: [ self-hosted, label-1 ] ``` Использование среды `ent/`: ```yaml runs-on: group: ent/my-group labels: [ self-hosted, label-1 ] ``` ## `jobs..environment` Используется `jobs..environment` для определения среды, на которую ссылается задание. Вы можете указать среду в виде только имени среды `name` или в виде объекта среды с `name` и `url`. URL-адрес сопоставляется с `environment_url` в API развертываний. Дополнительные сведения об API развертываний см. в разделе [Конечные точки REST API для репозиториев](/ru/enterprise-server@3.22/rest/repos#deployments). > \[!NOTE] > Все правила защиты развертывания должны передаваться перед отправкой задания, ссылающегося на среду, в средство выполнения. Дополнительные сведения см. в разделе [Управление средами для развертывания](/ru/enterprise-server@3.22/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments). ### Пример. Использование только имени среды ```yaml environment: staging_environment ``` ### Пример. Использование имени среды и URL-адреса ```yaml environment: name: production_environment url: https://github.com ``` Значение `url` может быть выражением. Контексты разрешенных выражений: [`github`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#github-context), \[[`inputs``job``runner`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#runner-context)`env`]\(/actions/reference/workflows-and-actions/contexts#env-context)и .[`steps`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#steps-context) Дополнительные сведения о выражениях см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions). ### Пример. Использование выходных данных в качестве URL-адреса ```yaml environment: name: production_environment url: ${{ steps.step_id.outputs.url_output }} ``` Значение `name` может быть выражением. Контексты разрешенных выражений: `github`[](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#github-context),`inputs`[](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#inputs-context) , `vars`[](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#vars-context),`needs`[](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#needs-context) ,`strategy`[](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#strategy-context) и .[`matrix`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#matrix-context) Дополнительные сведения о выражениях см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions). ### Пример. Использование выражения в качестве имени среды ```yaml environment: name: ${{ github.ref_name }} ``` ## `jobs..concurrency` Можно использовать `jobs..concurrency`, чтобы одновременно могли выполняться только одно задание или один процесс с использованием той же группы параллелизма. Группа параллелизма может представлять собой любую строку или выражение. Контексты разрешенных выражений: `github`[](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#github-context),`inputs`[](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#inputs-context) , `vars`[](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#vars-context),`needs`[](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#needs-context) ,`strategy`[](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#strategy-context) и .[`matrix`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#matrix-context) Дополнительные сведения о выражениях см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions). Можно также указать `concurrency` на уровне рабочего процесса. Дополнительные сведения см. в разделе [`concurrency`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#concurrency). Это означает, что в любое время в группе параллелизма может быть не более одного запущенного и одного ожидающего задания. Если параллельное задание или рабочий процесс добавлены в очередь и выполняется другое задание или рабочий процесс, использующие ту же группу параллелизма в репозитории, то находящиеся в очереди задание или рабочий процесс будут `pending`. Любое существующее `pending` задание или рабочий процесс в той же группе параллелизма, если она существует, будет отменена, а новое задание или рабочий процесс в очереди будет выполняться. Чтобы также отменить задание или рабочий процесс, которые сейчас выполняются в той же группе параллелизма, укажите `cancel-in-progress: true`. Чтобы условно отменить выполняемые в настоящее время задания или рабочие процессы в той же группе параллелизма, можно указать `cancel-in-progress` как выражение с любым из контекстов разрешенного выражения. > \[!NOTE] > > * Имя группы параллелизма не учитывает регистр. Например, `prod` и `Prod` будет рассматриваться как та же группа параллелизма. > * Задания или рабочие процессы в одной и той же группе параллелизма обрабатываются в порядке «первый вошёл — первый ушёл» (FIFO) в зависимости от времени ожидания группы параллелизма, а не по времени отправки каждого рабочего процесса. Поскольку фактическое время начала работы или запуска может различаться, заказ не гарантируется. ### Пример. Использование параллелизма и поведения по умолчанию По умолчанию GitHub Actions режим позволяет выполнять несколько заданий или рабочих процессов одновременно. Ключевое `concurrency` слово позволяет управлять параллелизмом выполнения рабочих процессов. Например, ключевое `concurrency` слово можно использовать сразу после определения условий триггера, чтобы ограничить параллелизм всего рабочего процесса для определенной ветви: ```yaml on: push: branches: - main concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` Кроме того, можно ограничить параллелизм заданий в рабочем процессе с помощью `concurrency` ключевого слова на уровне задания: ```yaml 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` группе параллелизма, которые уже выполняются, будут отменены. ```yaml jobs: job-1: runs-on: ubuntu-latest concurrency: group: staging_environment cancel-in-progress: true ``` Кроме того, использование динамического выражения, например `concurrency: ci-${{ github.ref }}` в рабочем процессе, означает, что рабочий процесс или задание будет частью группы `ci-` параллелизма, за которой следует ссылка на ветвь или тег, активировавший рабочий процесс. В этом примере, если новая фиксация отправляется в основную ветвь, пока предыдущий запуск по-прежнему выполняется, предыдущий запуск будет отменен, а новый будет запущен: ```yaml on: push: branches: - main concurrency: group: ci-${{ github.ref }} cancel-in-progress: true ``` ### Пример. Использование параллелизма для отмены любого выполняющегося задания или запуска Чтобы использовать параллелизм для отмены любой текущей задачи или запускаGitHub Actions, вы можете использовать `concurrency` ключ с опцией`true`:`cancel-in-progress` ```yaml concurrency: group: ${{ github.ref }} cancel-in-progress: true ``` Обратите внимание, что в этом примере, без определения конкретной группы параллелизма, GitHub Actions\_будет отменён любой\_ текущий запуск задания или рабочего процесса. ### Пример. Использование резервного значения Если вы создаете имя группы со свойством, определенным только для определенных событий, можно использовать резервное значение. Например, `github.head_ref` определяется только для событий `pull_request`. Если рабочий процесс реагирует на другие события в дополнение к событиям `pull_request`, необходимо предоставить резервное значение, чтобы избежать синтаксической ошибки. Следующая группа параллелизма отменяет выполняемые задания или запуски только в событиях `pull_request`. Если параметр `github.head_ref` не определен, группа параллелизма перейдет к идентификатору запуска, который будет гарантированно заданным и уникальным. ```yaml concurrency: group: ${{ github.head_ref || github.run_id }} cancel-in-progress: true ``` ### Пример. Отмена только выполняемых заданий или запусков для текущего рабочего процесса При наличии нескольких рабочих процессов в одном репозитории имена групп параллелизма должны быть уникальными в разных рабочих процессах, чтобы избежать отмены выполняемых заданий или запусков из других рабочих процессов. В противном случае все ранее выполняемые или ожидающие задания будут отменены независимо от рабочего процесса. Чтобы отменить только выполняемые запуски для одного рабочего процесса, можно использовать свойство `github.workflow` для создания группы параллелизма: ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` ### Пример. Отмена только выполняемых заданий в определенных ветвях Если вы хотите отменить выполняемые задания в определенных ветвях, но не на других, можно использовать условные выражения с `cancel-in-progress`. Например, это можно сделать, если вы хотите отменить выполняемые задания в ветвях разработки, но не в ветвях выпуска. Чтобы отменить выполнение только выполняемых запусков одного рабочего процесса, если он не запущен в ветви выпуска, можно задать `cancel-in-progress` выражение, аналогичное следующему: ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: ${{ !contains(github.ref, 'release/')}} ``` В этом примере несколько push-уведомлений в `release/1.2.3` ветвь не отменяют выполняемые запуски. Отправка в другую ветвь, например `main`, отменяет выполняемые запуски. ## `jobs..outputs` Можно использовать `jobs..outputs` для создания `map` выходных данных для задания. Выходные данные задания доступны для всех подчиненных заданий, которые зависят от этого задания. Дополнительные сведения об определении зависимостей заданий см. в разделе [`jobs..needs`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds). Выходные данные могут составлять не более 1 МБ на задание. Общий объем выходных данных в выполнении рабочего процесса не может превышать 50 МБ. Размер приблизительный на основе кодировки UTF-16. Выходные данные задания, содержащие выражения, вычисляются в средстве выполнения в конце каждого задания. Выходные данные, содержащие секреты, редактируются в средстве выполнения и не отправляются в GitHub Actions. Если выходные данные пропущены, так как он может содержать секрет, появится следующее предупреждение: "Пропустить выходные данные `{output.Key}` , так как он может содержать секрет". Дополнительные сведения об обработке секретов см. в [примере: маскирование и передача секрета между заданиями или рабочими процессами](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#example-masking-and-passing-a-secret-between-jobs-or-workflows). Чтобы применять выходные данные задания в зависимом задании, можно использовать контекст `needs`. Дополнительные сведения см. в разделе [Справочник по контекстам](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#needs-context). ### Пример: определение выходных данных для задания ```yaml 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" ``` ### Использование выходных данных задания в матрицном задании Матрицы можно использовать для создания нескольких выходных данных разных имен. При использовании матрицы выходные данные заданий будут объединены из всех заданий внутри матрицы. ```yaml 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..env` Переменные `map` , доступные для всех шагов в задании. Можно задать переменные для всего рабочего процесса или отдельного шага. Дополнительные сведения см. в разделах [`env`](#env) и [`jobs..steps[*].env`](#jobsjob_idstepsenv). При определении нескольких переменных среды с тем же именем GitHub использует самую конкретную переменную. Например, переменная среды, определенная на шаге, переопределяет переменные задания и среды рабочего процесса с тем же именем, а шаг выполняется. Переменная среды, определенная для задания, переопределяет переменную рабочего процесса с тем же именем, а задание выполняется. ### Пример `jobs..env` ```yaml jobs: job1: env: FIRST_NAME: Mona ``` ## `jobs..defaults` Используйте `jobs..defaults` для создания `map` с параметрами по умолчанию, которые будут применяться ко всем шагам задания. Вы также можете задать параметры по умолчанию для всего рабочего процесса. Дополнительные сведения см. в разделе [`defaults`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#defaults). Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе. ## `jobs..defaults.run` Использует `jobs..defaults.run` для предоставления параметры по умолчанию `shell` и `working-directory` для всех этапов `run` в задании. Можно указать параметры по умолчанию `shell` и `working-directory` для всех этапов [`run`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsrun) в задании. Вы также можете задать параметры по умолчанию для `run` для всего рабочего процесса. Дополнительные сведения см. в разделе [`defaults.run`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#defaultsrun). Их можно переопределить на `jobs..defaults.run` уровнях и `jobs..steps[*].run` уровнях. Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе. ## `jobs..defaults.run.shell` Используется `shell` для определения `shell` шага. Это ключевое слово может ссылаться на несколько контекстов. Дополнительные сведения см. в разделе ["Контексты](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability)". | Поддерживаемая платформа | `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..defaults.run.working-directory` Используется `working-directory` для определения рабочего каталога для `shell` шага. Это ключевое слово может ссылаться на несколько контекстов. Дополнительные сведения см. в разделе ["Контексты](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability)". > \[!TIP] > Перед запуском оболочки убедитесь, что `working-directory` назначаемая функция существует в средстве выполнения. > Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе. ### Пример. Настройка параметров этапа по умолчанию `run` для задания ```yaml jobs: job1: runs-on: ubuntu-latest defaults: run: shell: bash working-directory: ./scripts ``` ## `jobs..steps` Задание содержит последовательность задач, называемых шагами (`steps`). Шаги могут выполнять команды, задачи установки или действия в репозитории, общедоступном репозитории или в реестре Docker. Не все шаги выполняют действия, но все действия выполняются как шаги. Каждый шаг выполняется в собственном процессе в среде средства выполнения и имеет доступ к рабочей области и файловой системе. Так как шаги выполняются в собственном процессе, изменения переменных среды не сохраняются между шагами. GitHub предоставляет встроенные шаги для организации и завершения работы. GitHub Отображается только первые 1000 проверок, однако вы можете выполнять неограниченное количество шагов, если находитесь в пределах лимитов использования рабочего процесса. Для получения дополнительной информации см. [Выставление счетов и использование](/ru/enterprise-server@3.22/actions/concepts/billing-and-usage) для GitHub-hosted runners и [Ограничения действий](/ru/enterprise-server@3.22/actions/reference/limits) для самостоятельных ограничений использования бегунов. ### Пример `jobs..steps` ```yaml 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..steps[*].id` Уникальный идентификатор шага. Вы можете использовать `id` для ссылки на шаг в контекстах. Дополнительные сведения см. в разделе [Справочник по контекстам](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts). ## `jobs..steps[*].if` Условное выражение `if` можно использовать для предотвращения выполнения шага, если условие не выполняется. Для создания условного выражения можно использовать любой поддерживаемый контекст и любое выражение. Дополнительные сведения о том, какие контексты поддерживаются в этом ключе, см. в разделе [Справочник по контекстам](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability). При использовании выражений в условном `if` режиме можно, при необходимости, опустить синтаксис выражения `${{ }}`, так как GitHub Actions автоматически вычисляет условное `if` выражение как выражение. Однако это исключение не применяется везде. Всегда следует использовать синтаксис выражения `${{ }}`концевого выражения %} или экранировать с `''`, `""`либо `()` когда выражение начинается с `!`, так как `!` зарезервировано нотация в формате YAML. Например: {% raw %} ```yaml if: ${{ ! startsWith(github.ref, 'refs/tags/') }} ``` Для получения дополнительной информации см. [Оценка выражений в рабочих процессах и действиях](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions). ### Пример. Использование контекстов Этот шаг выполняется, только если типом события является `pull_request`, а действием — `unassigned`. ```yaml 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` выполняется только при сбое предыдущего шага задания. Дополнительные сведения см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions#status-check-functions). ```yaml 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 }}` , в примере), будет пустой строкой. ```yaml 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 и [Справочник по контекстам](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability)]\(/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets). ## `jobs..steps[*].name` Название для вашего шага для отображения на GitHub. ## `jobs..steps[*].uses` Выбирает действие, которое будет выполняться как часть шага вашего задания. Действие — это многократно используемая единица кода. Вы можете использовать действие, определенное в том же репозитории, что и рабочий процесс, в общедоступном репозитории или в [опубликованном образе контейнера Docker](https://hub.docker.com/). Мы настоятельно рекомендуем включить версию используемого вами действия, указав ссылку на Git, SHA или тег Docker. Если вы не укажете версию, это может нарушить ваши рабочие процессы или вызвать непредвиденное поведение, когда владелец действия будет публиковать обновление. * Использование SHA фиксации выпущенной версии действия является самым безопасным для стабильности и защиты. * Если действие публикует теги основного номера версий, вам следует ожидать получения критических исправлений и обновлений для системы безопасности. При этом совместимость сохранится. Обратите внимание, что это поведение выполняется по усмотрению автора действия. * Использование ветви действия по умолчанию может быть удобным, но если кто-то выпустит новую основную версию с критическим изменением, ваш рабочий процесс может прерваться. Для некоторых действий требуются входные данные, заданные с помощью ключевого слова [`with`](#jobsjob_idstepswith). Просмотрите файл README действия, чтобы определить необходимые ввода. Действия — это файлы JavaScript или контейнеры Docker. Если используемое действие является контейнером Docker, необходимо запустить задание в среде Linux. Дополнительные сведения см. в статье [`runs-on`](#jobsjob_idruns-on). ### Пример. Использование действий с версиями ```yaml steps: # Reference a specific commit - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3 # Reference the major version of a release - uses: actions/checkout@v6 # Reference a specific version - uses: actions/checkout@v6.2.0 # Reference a branch - uses: actions/checkout@main ``` ### Пример. Использование общедоступного действия `{owner}/{repo}@{ref}` Вы можете указать ветку, ссылку или SHA в публичном GitHub репозитории. ```yaml 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. ```yaml jobs: my_first_job: steps: - name: My first step uses: actions/aws/ec2@main ``` ### Пример. Использование действия в том же репозитории, что и рабочий процесс при выполнении фиксации (рекомендуется) `$/path/to/action` Префикс `$/` — это ссылка на самостоятельный репозиторий. Он ссылается на действие, хранящееся в том же репозитории, что и рабочий процесс или действие, которое в настоящее время выполняется, и разрешает это репозиторий при выполнении фиксации (то же SHA, что и выполняющийся рабочий процесс или действие). Сначала не нужно извлечь репозиторий, поэтому рекомендуется ссылаться на действие в собственном репозитории. Синтаксис `$/` недоступен в GitHub Enterprise Server. Ссылка `$/` не должна включать `@{ref}` суффикс. Ссылка всегда является фиксацией выполняемого рабочего процесса или действия, поэтому ссылка, например `$/actions/my-action@v1` недопустимая. `$/` всегда разрешает репозиторий файла, в который он отображается, а не репозиторий, который его назвал. Например, если повторно используемый рабочий процесс в одном репозитории вызывается рабочим процессом в другом репозитории, `$/` ссылка в вызываемом рабочем процессе разрешается в репозиторий вызываемого рабочего процесса, а не в репозитории вызывающего рабочего процесса. Это делает `$/` надежным для композиции действий, где относительный `./` путь вместо этого будет разрешать против того, что извлечено в рабочей области вызывающего объекта. Сведения об использовании `$/` в шагах составного действия см. в разделе [Справочник по синтаксису метаданных](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/metadata-syntax#runsstepsuses). В следующей таблице сравниваются способы ссылки на действие. | Syntax | Разрешение на | Рекомендуется для | | ---------------------- | ----------------------------------------------------------------------------------------------------------------- | ----------------------------- | | `$/path/to/action` | Тот же репозиторий, что и запущенный рабочий процесс или действие, при выполнении фиксации | Действия в одном репозитории | | `{owner}/{repo}@{ref}` | Указанный репозиторий по указанному ссылке | Действия в другом репозитории | | `./path/to/action` | Путь к извлеченной рабочей области runner относительно рабочего каталога по умолчанию (`${{ github.workspace }}`) | Только пограничные случаи | ```yaml on: [push] jobs: my_first_job: runs-on: ubuntu-latest steps: # References an action in the same repository at the running commit - uses: $/.github/actions/hello-world-action ``` ### Пример. Использование действия в том же репозитории, что и рабочий процесс `./path/to/dir` Путь к каталогу, содержащему действие в репозитории рабочего процесса. Перед использованием действия необходимо извлечь репозиторий, а `./` путь разрешается в рабочей области runner, а не в репозитории выполняемого рабочего процесса. В большинстве случаев используйте приведенный `$/` выше синтаксис. Пример структуры файла репозитория: ```shell |-- hello-world (repository) | |__ .github | └── workflows | └── my-first-workflow.yml | └── actions | |__ hello-world-action | └── action.yml ``` Путь является относительным (`./`) к рабочему каталогу по умолчанию (`github.workspace`, `$GITHUB_WORKSPACE`). Если действие извлекает репозиторий в расположение, отличное от рабочего процесса, необходимо обновить относительный путь, используемый для локальных действий. Пример файла рабочего процесса: ```yaml jobs: my_first_job: runs-on: ubuntu-latest steps: # This step checks out a copy of your repository. - name: My first step - check out repository uses: actions/checkout@v6 # This step references the directory that contains the action. - name: Use local hello-world-action uses: ./.github/actions/hello-world-action ``` ### Пример. Использование действия Docker Hub `docker://{image}:{tag}` Образ Docker, опубликованный в [Docker Hub](https://hub.docker.com/). ```yaml jobs: my_first_job: steps: - name: My first step uses: docker://alpine:3.8 ``` ### Пример. Использование действия общедоступного реестра Docker `docker://{host}/{image}:{tag}` Образ Docker в общедоступном реестре. В этом примере используется реестр контейнеров Google: `gcr.io`. ```yaml jobs: my_first_job: steps: - name: My first step uses: docker://gcr.io/cloud-builders/gradle ``` ### Пример. Использование действия в частном репозитории, отличном от того, где выполняется рабочий процесс Если действие находится во внутреннем репозитории или в приватном репозитории, настроенном для доступа из репозитория вашего рабочего процесса, вы можете напрямую обратиться к этому действию. Дополнительные сведения см. в разделе [Управление настройками GitHub Actions для репозитория](/ru/enterprise-server@3.22/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository)[](/ru/enterprise-server@3.22/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-a-private-repository). Если действие не находится в репозитории, настроенном для доступа, нужно проверить репозиторий и ссылаться на действие локально. Сгенерируйте a personal access token и добавьте токен как секрет. Следующий пример демонстрирует этот способ ссылки на действие. Дополнительные сведения см. в разделе \[AUTOTITLE и [Управление личными маркерами доступа](/ru/enterprise-server@3.22/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)]\(/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets). Замените `PERSONAL_ACCESS_TOKEN` в примере именем секрета. ```yaml jobs: my_first_job: steps: - name: Check out repository uses: actions/checkout@v6 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 ``` В качестве альтернативы используйте a GitHub App вместо a personal access token , чтобы ваш рабочий процесс продолжался даже если personal access token владелец уходит. Дополнительные сведения см. в разделе [Создание аутентифицированных запросов API с помощью приложения GitHub в рабочем процессе GitHub Actions](/ru/enterprise-server@3.22/apps/creating-github-apps/authenticating-with-a-github-app/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow). ## `jobs..steps[*].run` Запускает программы командной строки, не превышающие 21 000 символов с помощью оболочки операционной системы. Если `name` не указано, в качестве имени шага по умолчанию используется текст, указанный в команде `run`. Команды выполняются с помощью оболочки, не требующей входа, по умолчанию. Вы можете выбрать другую оболочку и настроить ее для выполнения команд. Дополнительные сведения см. в разделе [`jobs..steps[*].shell`](#jobsjob_idstepsshell). Каждое ключевое слово `run` представляет новый процесс и оболочку в среде средства выполнения. При предоставлении команд с несколькими строками каждая строка выполняется в той же оболочке. Например: * Команда с одной строкой: ```yaml - name: Install Dependencies run: npm install ``` * Команда с несколькими строками: ```yaml - name: Clean install dependencies and build run: | npm ci npm run build ``` ## `jobs..steps[*].working-directory` С помощью ключевого слова `working-directory` можно указать рабочий каталог, в котором будет выполняться команда. ```yaml - name: Clean temp directory run: rm -rf * working-directory: ./temp ``` Кроме того, можно указать рабочий каталог по умолчанию для всех `run` шагов в задании или для всех `run` шагов всего рабочего процесса. Дополнительные сведения см. в разделах [`defaults.run.working-directory`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#defaultsrunworking-directory) и [`jobs..defaults.run.working-directory`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrunworking-directory). Вы также можете использовать `run` шаг для запуска скрипта. Дополнительные сведения см. в разделе [Добавление сценариев в рабочий процесс](/ru/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/add-scripts). ## `jobs..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`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#defaultsrunshell) и [`jobs..defaults.run.shell`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrunshell). ### Пример. Выполнение команды с помощью Bash ```yaml steps: - name: Display the path shell: bash run: echo $PATH ``` ### Пример. Выполнение команды с помощью Windows `cmd` ```yaml steps: - name: Display the path shell: cmd run: echo %PATH% ``` ### Пример. Выполнение команды с помощью PowerShell Core ```yaml steps: - name: Display the path shell: pwsh run: echo ${env:PATH} ``` ### Пример. Использование PowerShell Desktop для выполнения команды ```yaml steps: - name: Display the path shell: powershell run: echo ${env:PATH} ``` ### Пример. Выполнение встроенного скрипта Python ```yaml steps: - name: Display the path shell: python run: | import os print(os.environ['PATH']) ``` ### Пользовательская оболочка Вы можете задать для значения `shell` строку шаблона с помощью `command [options] {0} [more_options]`. GitHub интерпретирует первое слово строки, разделённое пробелами, как команду и вставляет имя файла временного скрипта в `{0}`. Например: ```yaml steps: - name: Display the environment variables and their values shell: perl {0} run: | print %ENV ``` Используемая команда, в этом примере `perl`, должна быть установлена в средстве выполнения. ### Коды выхода и настройки действий в случае ошибок Для встроенных shell-ключевых слов мы предоставляем следующие параметры по умолчанию, которые выполняются GitHub-hosted runners. Эти рекомендации следует использовать при выполнении скриптов оболочки. * `bash` / `sh`: * По умолчанию для обоих и `set -e`для обоих `sh` используется принудительное поведение сбоем`bash`. При `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..steps[*].with` `map` параметров ввода, определяемых действием. Каждый параметр ввода представляет собой пару "ключ-значение". Параметры ввода задаются как переменные среды. Переменная имеет префикс `INPUT_` и преобразуется в верхний регистр. Входные параметры, определенные для контейнера Docker, должны использоваться `args`. Дополнительные сведения см. в разделе [`jobs..steps[*].with.args`](#jobsjob_idstepswithargs). ### Пример `jobs..steps[*].with` Определяет три входных параметра (`first_name`, `middle_name` и `last_name`), определенные действием `hello_world`. Эти входные переменные будут доступны для действия `hello-world` как переменные среды `INPUT_FIRST_NAME`, `INPUT_MIDDLE_NAME` и `INPUT_LAST_NAME`. ```yaml 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..steps[*].with.args` Строка `string`, определяющая входные данные для контейнера Docker. GitHub передаёт `args``ENTRYPOINT` контейнеры контейнерам, когда контейнер запускается. `array of strings` не поддерживается этим параметром. Один аргумент, содержащий пробелы, должен быть окружен двойными кавычками `""`. ### Пример `jobs..steps[*].with.args` ```yaml 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`, следуйте этим рекомендациям, упорядоченным по предпочтительности: 1. Задокументируйте обязательные аргументы в README действия и опустите их из инструкции `CMD`. 2. Используйте значения по умолчанию, позволяющие использовать действие без указания `args`. 3. Если действие предоставляет флаг `--help` или что-то подобное, используйте его по умолчанию, чтобы действие документировало само себя. ## `jobs..steps[*].with.entrypoint` Переопределяет параметр `ENTRYPOINT` Docker в `Dockerfile` или задает его, если он еще не был указан. В отличие от инструкции Docker `ENTRYPOINT`, которая имеет форму оболочки и выполнения, ключевое слово `entrypoint` принимает только одну строку, определяющую исполняемый файл для запуска. ### Пример `jobs..steps[*].with.entrypoint` ```yaml steps: - name: Run a custom command uses: octo-org/action-name@main with: entrypoint: /a/different/executable ``` Ключевое слово `entrypoint` предназначено для использования с действиями контейнера Docker, но его также можно использовать с действиями JavaScript, которые не определяют входные данные. ## `jobs..steps[*].env` Задает переменные для шагов, используемых в среде запуска. Можно также задать переменные для всего рабочего процесса или задания. Дополнительные сведения см. в разделах [`env`](#env) и [`jobs..env`](#jobsjob_idenv). При определении нескольких переменных среды с тем же именем GitHub использует самую конкретную переменную. Например, переменная среды, определенная на шаге, переопределяет переменные задания и среды рабочего процесса с тем же именем, а шаг выполняется. Переменная среды, определенная для задания, переопределяет переменную рабочего процесса с тем же именем, а задание выполняется. Общедоступные действия могут указывать ожидаемые переменные в файле README. Если вы задаете секретное или конфиденциальное значение, например пароль или маркер, необходимо задать секреты с помощью контекста `secrets` . Дополнительные сведения см. в разделе [Справочник по контекстам](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts). ### Пример `jobs..steps[*].env` ```yaml steps: - name: My first action env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} FIRST_NAME: Mona LAST_NAME: Octocat ``` ## `jobs..steps[*].continue-on-error` Предотвращает сбой задания при сбое шага. Задайте значение `true`, чтобы задание считалось выполненным при сбое этого шага. ## `jobs..steps[*].timeout-minutes` Максимальное количество минут для выполнения шага перед завершением процесса. Максимум: 360 как GitHubдля ведущих, так и для самостоятельных бегунов. Дробные значения не поддерживаются. `timeout-minutes` должно быть положительным целым числом. ## `jobs..timeout-minutes` Максимальное количество минут для запуска задания GitHub автоматически отменяет её. Значение по умолчанию: 360 Если время ожидания превышает ограничение по времени выполнения задания для средства выполнения, задание будет отменено, когда будет достигнуто ограничение времени выполнения. Для получения дополнительной информации о сроках выполнения заданий см. [Выставление счетов и использование](/ru/enterprise-server@3.22/actions/concepts/billing-and-usage#usage-limits-and-policy) для GitHub-hosted runners и [Ограничения действий](/ru/enterprise-server@3.22/actions/reference/limits) для лимитов использования самостоятельных пользователей. > \[!NOTE] > Срок действия `GITHUB_TOKEN` истекает при завершении задания или в течение не более 24 часов. Для самостоятельных пользователей токен может быть ограничивающим фактором, если тайм-аут превышает 24 часа. Дополнительные сведения об этом `GITHUB_TOKEN`см. в разделе [Использование GITHUB\_TOKEN для проверки подлинности в рабочих процессах](/ru/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token). ## `jobs..strategy` Используйте `jobs..strategy` для применения стратегии матрицы к заданиям. Стратегия матрицы позволяет использовать переменные в одном определении задания для автоматического создания нескольких выполнений заданий, основанных на сочетаниях переменных. Например, можно использовать стратегию матрицы для тестирования кода в нескольких версиях языка или в нескольких операционных системах. Для получения дополнительной информации см. [Выполнение вариантов заданий в рабочем процессе](/ru/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations). ## `jobs..strategy.matrix` Используйте `jobs..strategy.matrix` для создания матрицы различных конфигураций заданий Дополнительные сведения см. в разделе [Выполнение вариантов заданий в рабочем процессе](/ru/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations). Матрица создаст не более 256 заданий для каждого выполнения рабочего процесса. Это ограничение распространяется как GitHubна -hosting, так и на самостоятельных бегунов. Переменные, которые вы определяете, становятся свойствами в контексте `matrix`, и можно ссылаться на это свойство в других областях файла рабочего процесса. В этом примере можно использовать `matrix.version` и `matrix.os`, чтобы получить доступ к текущим значениям `version` и `os`, которые использует задание. Дополнительные сведения см. в разделе [Справочник по контекстам](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts). По умолчанию GitHub максимальное количество параллельных заданий в зависимости от доступности раннера. Порядок переменных в матрице определяет порядок создания заданий. Первая переменная, которую вы определите, будет первым заданием, созданным в ходе выполнения рабочего процесса. ### Использование матрицы с одним измерением Следующий рабочий процесс определяет переменную `version` со значениями `[10, 12, 14]`. Рабочий процесс будет выполнять три задания, по одному для каждого значения в переменной. Каждое задание будет получать доступ к значению `version` через контекст `matrix.version` и передавать значение `node-version` в действие `actions/setup-node`. ```yaml jobs: example_matrix: strategy: matrix: version: [10, 12, 14] steps: - uses: actions/setup-node@v7 with: node-version: ${{ matrix.version }} ``` ### Использование многомерной матрицы Укажите несколько переменных для создания многомерной матрицы. Задание будет выполняться для каждой возможной комбинации переменных. Например, для следующего рабочего процесса устанавливаются две переменные: * Две операционные системы, указанные в переменной `os` * Три версии Node.js, указанные в переменной `version` Рабочий процесс будет выполнять шесть заданий, по одному для каждой комбинации переменных `os` и `version`. В каждом задании параметру `runs-on` присваивается текущее значение `os` и передается текущее значение `version` в действие `actions/setup-node`. ```yaml jobs: example_matrix: strategy: matrix: os: [ubuntu-22.04, ubuntu-24.04] version: [10, 12, 14] runs-on: ${{ matrix.os }} steps: - uses: actions/setup-node@v7 with: node-version: ${{ matrix.version }} ``` Конфигурация переменной в матрице может иметь значение `array``object`s. Например, следующая матрица создает 4 задания с соответствующими контекстами. ```yaml matrix: os: - ubuntu-latest - macos-latest node: - version: 14 - version: 20 env: NODE_OPTIONS=--openssl-legacy-provider ``` Каждое задание в матрице будет иметь собственное сочетание `os` и `node` значения, как показано ниже. ```yaml - matrix.os: ubuntu-latest matrix.node.version: 14 - matrix.os: ubuntu-latest matrix.node.version: 20 matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider - matrix.os: macos-latest matrix.node.version: 14 - matrix.os: macos-latest matrix.node.version: 20 matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider ``` ## `jobs..strategy.matrix.include` Для каждого объекта в списке `include` пары ключ:значение в объекте будут добавлены к каждой из комбинаций матриц, если ни одна из пар ключ:значение не перезаписывает какие-либо исходные значения матрицы. Если объект не может быть добавлен в какие-либо комбинации матриц, будет создана новая. Обратите внимание, что исходные матричные значения не будут перезаписаны, но добавленные матричные значения могут быть перезаписаны. ### Пример. Развертывание конфигураций Например, следующий рабочий процесс будет выполнять четыре задания, по одному для каждого сочетания `os` и `node`. Если выполняется задание для значения `windows-latest` параметра `os` и значения `16` параметра `node`, в задание будет включена дополнительная переменная `npm` со значением `6`. ```yaml 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@v7 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`. ```yaml jobs: example_matrix: strategy: matrix: os: [macos-latest, windows-latest, ubuntu-latest] version: [12, 14, 16] include: - os: windows-latest version: 17 ``` Если не указать переменные матрицы, будут выполняться все конфигурации в `include`. Например, следующий рабочий процесс выполнит два задания, по одному для каждого элемента `include`. Это позволяет использовать не полностью заполненную матрицу. ```yaml jobs: includes_only: runs-on: ubuntu-latest strategy: matrix: include: - site: "production" datacenter: "site-a" - site: "staging" datacenter: "site-b" ``` ## `jobs..strategy.matrix.exclude` Исключенная конфигурация должна иметь хотя бы частичное совпадение, чтобы ее можно было исключить. Все `include` сочетания обрабатываются после `exclude`. Это позволяет использовать `include` для добавления обратных комбинаций, которые были ранее исключены. ## `jobs..strategy.fail-fast` Можно управлять обработкой сбоев заданий с помощью `jobs..strategy.fail-fast` и `jobs..continue-on-error`. `jobs..strategy.fail-fast` применяется ко всему тому. Если `jobs..strategy.fail-fast` задано значение `true` или его выражение оценивается `true`, GitHub отменит все выполняемые и очередные задания в матрице, если любое задание в матрице завершается ошибкой. По умолчанию свойство имеет значение `true`. `jobs..continue-on-error` применяется к одному заданию. Если `jobs..continue-on-error` имеет значение `true`, другие задания в матрице будут продолжать выполняться, даже если задание с `jobs..continue-on-error: true` завершается сбоем. Можно использовать `jobs..strategy.fail-fast` и `jobs..continue-on-error` совместно. Например, следующий рабочий процесс запустит четыре задания. Для каждого задания `continue-on-error` определяется значением `matrix.experimental`. При сбое любого из заданий с `continue-on-error: false` все выполняемые или помещенные в очередь задания будут отменены. При сбое задания с `continue-on-error: true` другие задания не будут затронуты. ```yaml 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..strategy.max-parallel` По умолчанию GitHub максимальное количество параллельных заданий в зависимости от доступности раннера. ## `jobs..continue-on-error` `jobs..continue-on-error` применяется к одному заданию. Если `jobs..continue-on-error` имеет значение `true`, другие задания в матрице будут продолжать выполняться, даже если задание с `jobs..continue-on-error: true` завершается сбоем. Предотвращает сбой выполнения рабочего процесса при сбое задания. Установите значение `true`, чтобы разрешить выполнение рабочего процесса в случае сбоя этого задания. ### Пример. Предотвращение сбоя рабочего процесса в случае сбоя определенного задания матрицы Можно разрешить сбой определенных заданий в матрице без сбоя всего рабочего процесса. Например, можно разрешить сбой экспериментального задания, у которого для `node` задано `15`, без сбоя рабочего процесса. ```yaml 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..container` > \[!NOTE] > Если в рабочих процессах используются действия контейнеров Docker, контейнеры заданий или контейнеры служб, необходимо использовать средство выполнения Linux: > > * При использовании размещенных в GitHub средств выполнения необходимо применять средство выполнения Ubuntu. > * Если вы применяете локальные средства выполнения, необходимо использовать компьютер Linux в качестве средства выполнения, а Docker нужно установить. Используйте `jobs..container` для создания контейнера для выполнения всех этапов задания, для которых еще не указан контейнер. При наличии этапов, которые используют действия скрипта и контейнера, действия контейнера будут выполняться как одноуровневые контейнеры в той же сети с теми же подключениями томов. Если `container` не задан, все этапы будут выполняться непосредственно на узле, указанном, `runs-on`, если только этап не относится к действию, настроенному на выполнение в контейнере. > \[!NOTE] > Оболочка по умолчанию для `run` шагов внутри контейнера `sh` вместо `bash`. Это значение может быть изменено на [`jobs..defaults.run`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrun) или [`jobs..steps[*].shell`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsshell). ### Пример. Выполнение задания в контейнере ```yaml copy 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`. ```yaml jobs: container-test-job: runs-on: ubuntu-latest container: node:18 ``` ## `jobs..container.image` Используйте `jobs..container.image` для определения образа Docker, который будет использоваться в качестве контейнера для выполнения действия. Значением может быть имя образа Docker Hub или имя реестра. > \[!NOTE] > Docker Hub обычно накладывает ограничения скорости для операций отправки и извлечения, которые повлияют на задания на локальных запусках. Однако GitHub, размещенные в runner, не подлежат этим ограничениям на основе соглашения между переменными данных.product.github %} и Docker. ## `jobs..container.credentials` Если реестру контейнеров образа требуется проверка подлинности для извлечения образа, можно использовать `jobs..container.credentials`, чтобы настроить `map` для `username` и `password`. Учетные данные являются теми же значениями, которые будут предоставлены команде [`docker login`](https://docs.docker.com/engine/reference/commandline/login/). ### Пример: определение учетных данных для реестра контейнеров ```yaml container: image: ghcr.io/owner/image credentials: username: ${{ github.actor }} password: ${{ secrets.github_token }} ``` ## `jobs..container.env` Используйте `jobs..container.env` для задания `map` переменных среды в контейнере. ## `jobs..container.ports` Используйте `jobs..container.ports` для задания `array` портов для использования в контейнере. ## `jobs..container.volumes` Используйте `jobs..container.volumes` для задания `array` томов, которые будет использовать контейнер. Тома можно использовать для совместного использования данных между службами или другими этапами в задании. Можно указать именованные тома Docker, анонимные тома Docker или подключения привязок на узле. Чтобы указать том, укажите путь к источнику и назначению: `:`. `` — это имя тома или абсолютный путь на хост-компьютере, а `` — это абсолютный путь в контейнере. ### Пример. Подключение томов в контейнере ```yaml volumes: - my_docker_volume:/volume_mount - /data/my_data - /source/directory:/destination/directory ``` ## `jobs..container.options` Используйте `jobs..container.options` для настройки дополнительных параметров ресурса контейнера Docker. Список параметров см. в разделе [`docker create` параметров](https://docs.docker.com/engine/reference/commandline/create/#options). > \[!WARNING] > Параметры `--network` и `--entrypoint` параметры не поддерживаются. ## `jobs..services` > \[!NOTE] > Если в рабочих процессах используются действия контейнеров Docker, контейнеры заданий или контейнеры служб, необходимо использовать средство выполнения Linux: > > * При использовании размещенных в GitHub средств выполнения необходимо применять средство выполнения Ubuntu. > * Если вы применяете локальные средства выполнения, необходимо использовать компьютер Linux в качестве средства выполнения, а Docker нужно установить. Используется для размещения контейнеров служб для задания в рабочем процессе. Контейнеры служб полезны для создания баз данных или служб кэша, таких как Redis. Средство выполнения автоматически создает сеть Docker и управляет жизненным циклом контейнеров служб. Если вы настраиваете задание для выполнения в контейнере или шаг использует действия контейнера, вам не нужно сопоставлять порты для доступа к службе или действию. Docker автоматически предоставляет все порты между контейнерами в одной сети моста, определяемой пользователем Docker. Вы можете напрямую ссылаться на контейнер службы по имени узла. Имя узла автоматически сопоставляется с именем метки, настроенной для службы в рабочем процессе. Если вы настраиваете задание для запуска непосредственно на компьютере средства выполнения, а шаг не использует действие контейнера, необходимо сопоставить все необходимые порты контейнера службы Docker с узлом Docker (компьютер средства выполнения). Доступ к контейнеру службы можно получить с помощью localhost и сопоставленного порта. Дополнительные сведения о различиях между контейнерами сетевых служб см. в разделе [Взаимодействие с контейнерами служб Docker](/ru/enterprise-server@3.22/actions/tutorials/use-containerized-services/use-docker-service-containers). ### Пример. Использование localhost В этом примере создаются две службы: nginx и redis. При указании порта контейнера, но не узла порт контейнера случайным образом назначается свободному порту на узле. GitHub устанавливает `${{job.services..ports}}` назначенный хост-порт в контексте. В этом примере вы можете получить доступ к портам хоста сервиса с помощью `${{ job.services.nginx.ports['80'] }}` контекстов и `${{ job.services.redis.ports['6379'] }}` ```yaml 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..services..image` Образ Docker для использования в качестве контейнера для выполнения действия. Значением может быть имя образа Docker Hub или имя реестра. Если `jobs..services..image` назначена пустая строка, служба не запустится. Это можно использовать для настройки условных служб, как показано в следующем примере. ```yaml services: nginx: image: ${{ options.nginx == true && 'nginx' || '' }} ``` ## `jobs..services..credentials` Если реестру контейнеров образа требуется проверка подлинности для извлечения образа, можно использовать `jobs..container.credentials`, чтобы настроить `map` для `username` и `password`. Учетные данные являются теми же значениями, которые будут предоставлены команде [`docker login`](https://docs.docker.com/engine/reference/commandline/login/). ### Пример `jobs..services..credentials` ```yaml 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..services..env` Задает `map` переменных среды в контейнере службы. ## `jobs..services..ports` Задает `array` портов для предоставления в контейнере службы. ## `jobs..services..volumes` Задает `array` тома для используемого контейнера службы. Тома можно использовать для совместного использования данных между службами или другими этапами в задании. Можно указать именованные тома Docker, анонимные тома Docker или подключения привязок на узле. Чтобы указать том, укажите путь к источнику и назначению: `:`. `` — это имя тома или абсолютный путь на хост-компьютере, а `` — это абсолютный путь в контейнере. ### Пример `jobs..services..volumes` ```yaml volumes: - my_docker_volume:/volume_mount - /data/my_data - /source/directory:/destination/directory ``` ## `jobs..services..options` Дополнительные параметры ресурса контейнера Docker. Список параметров см. в разделе [`docker create` параметров](https://docs.docker.com/engine/reference/commandline/create/#options). > \[!WARNING] > Параметр `--network` не поддерживается. ## `jobs..uses` Расположение и версия повторно используемого файла рабочего процесса для запуска в качестве задания. Используйте один из следующих синтаксисов: * `$/.github/workflows/{filename}` для повторного использования рабочего процесса в одном репозитории. Это рекомендуемый синтаксис для ссылки на повторно используемый рабочий процесс в одном репозитории. Этот синтаксис недоступен в GitHub Enterprise Server. * `{owner}/{repo}/.github/workflows/{filename}@{ref}` для повторно используемых рабочих процессов в общедоступных, внутренних и частных репозиториях. * `./.github/workflows/{filename}` для повторно используемых рабочих процессов в одном репозитории. При ссылке на повторно используемый рабочий процесс и `{owner}/{repo}``@{ref}`может `{ref}` быть SHA, тег выпуска или имя ветви. Если тег выпуска и ветвь имеют то же имя, тег выпуска имеет приоритет над именем ветви. Использование sha фиксации является самым безопасным вариантом для стабильности и безопасности. Дополнительные сведения см. в разделе [Справочник по безопасному использованию](/ru/enterprise-server@3.22/actions/reference/security/secure-use#reusing-third-party-workflows). При ссылке на повторно используемый рабочий процесс в том же репозитории или `$/``./` (без `{owner}/{repo}` и), вызываемый рабочий процесс создается из той же фиксации, что и `@{ref}`рабочий процесс вызывающего объекта. Ссылка `$/` не должна включать `@{ref}` суффикс и `$/` недоступна в GitHub Enterprise Server. Префиксы ссылок, такие как `refs/heads` и `refs/tags` не допускаются. В этом ключевом слове нельзя использовать контексты или выражения. ### Пример `jobs..uses` ```yaml 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 # The `$/` syntax is not available in GitHub Enterprise Server. call-workflow-in-same-repo-at-running-commit: uses: $/.github/workflows/workflow-2.yml call-workflow-in-another-repo: uses: octo-org/another-repo/.github/workflows/workflow.yml@v1 ``` Дополнительные сведения см. в разделе [Повторное использование рабочих процессов](/ru/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows). ## `jobs..with` Если задание используется для вызова многократно используемого рабочего процесса, можно использовать `with` для предоставления карты входных данных, передаваемых в вызываемый рабочий процесс. Все входные данные, которые вы передаете, должны соответствовать спецификациям ввода, определенным в вызываемом рабочем процессе. В отличие от [`jobs..steps[*].with`](#jobsjob_idstepswith)того, какие входные данные передаются `jobs..with` , недоступны в виде переменных среды в вызываемом рабочем процессе. Вместо этого можно ссылаться на входные данные с помощью контекста `inputs`. ### Пример `jobs..with` ```yaml jobs: call-workflow: uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main with: username: mona ``` ## `jobs..with.` Пара, состоящая из строкового идентификатора для входных данных и значения входных данных. Идентификатор должен соответствовать имени входных данных, определенных [`on.workflow_call.inputs.`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/metadata-syntax#inputsinput_id) в вызываемом рабочем процессе. Тип данных значения должен соответствовать типу, определенному [`on.workflow_call.inputs..type`](#onworkflow_callinputsinput_idtype) в вызываемом рабочем процессе. Допустимые контексты выражений: `github` и `needs`. ## `jobs..secrets` Если задание используется для вызова многократно используемого рабочего процесса, можно использовать `secrets` для предоставления карты секретов, передаваемых в вызываемый рабочий процесс. Все секретные данные, которые вы передаете, должны соответствовать именам, определенным в вызываемом рабочем процессе. ### Пример `jobs..secrets` ```yaml jobs: call-workflow: uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main secrets: access-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }} ``` ## `jobs..secrets.inherit` Используйте ключевое слово `inherit` для передачи всех секретов вызывающего рабочего процесса в вызываемой рабочий процесс. Сюда входят все секреты, к которым у вызывающего рабочего процесса есть доступ, то есть секреты организации, репозитория и среды. Ключевое слово `inherit` можно использовать для передачи секретов между репозиториями в одной организации или между организациями в пределах одного предприятия. ### Пример `jobs..secrets.inherit` ```yaml on: workflow_dispatch: jobs: pass-secrets-to-workflow: uses: ./.github/workflows/called-workflow.yml secrets: inherit ``` ```yaml 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..secrets.` Пара, состоящая из строкового идентификатора для секрета и значения секрета. Идентификатор должен соответствовать имени секрета, определенного [`on.workflow_call.secrets.`](#onworkflow_callsecretssecret_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. Если вы начинаете шаблон с `*`, `[` или `!`, необходимо заключить шаблон в кавычки. Кроме того, при использовании [последовательности потоков](https://yaml.org/spec/1.2.2/#flow-sequences) с шаблоном, содержащим `[` и (или) `]`шаблон должен быть заключен в кавычки. ```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..`[](#onpushbranchestagsbranches-ignoretags-ignore),`on..`[](#onpull_requestpull_request_targetbranchesbranches-ignore) а [`on..paths`](#onpushpull_requestpull_request_targetpathspaths-ignore)также . ### Шаблоны для сопоставления ветвей и тегов | Расписание | Description | Примеры совпадений | | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | `feature/*` | Подстановочный знак `*` соответствует любому символу, но не соответствует косой черте (`/`). | `feature/my-branch`

`feature/your-branch` | | `feature/**` | Подстановочный знак `**` соответствует любому символу, включая косую черту (`/`), в именах ветвей и тегов. | `feature/beta-a/my-branch`

`feature/your-branch`

`feature/mona/the/octocat` | | `main`

`releases/mona-the-octocat` | Соответствует точному имени ветви или тега. | `main`

`releases/mona-the-octocat` | | `'*'` | Соответствует всем именам ветвей и тегов, которые не содержат косую черту (`/`). Символ `*` является специальным символом в 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/mona/octocat.txt` | | `docs/**/*.md` | Файл с суффиксом `.md` в любом месте каталога `docs`. | `docs/README.md`

`docs/mona/hello-world.md`

`docs/a/markdown/file.md` | | `'**/docs/**'` | Любые файлы в каталоге `docs` в любом месте репозитория. | `docs/hello.md`

`dir/docs/my-file.txt`

`space/docs/plan/space.doc` | | `'**/README.md'` | Файл README.md в любом месте репозитория. | `README.md`

`js/README.md` | | `'**/*src/**'` | Любой файл в папке с суффиксом `src` в любом месте репозитория. | `a/src/app.js`

`my-src/code/js/app.js` | | `'**/*-post.md'` | Файл с суффиксом `-post.md` в любом месте репозитория. | `my-post.md`

`path/their-post.md` | | `'**/migrate-*.sql'` | Файл с префиксом `migrate-` и суффиксом `.sql` в любом месте репозитория. | `migrate-10909.sql`

`db/migrate-v1.0.sql`

`db/sept/migrate-v1.sql` | | `'*.md'`

`'!README.md'` | Использование восклицательного знака (`!`) перед шаблоном отменяет его. Если файл соответствует шаблону, а также соответствует отрицательному шаблону, определенному позже в файле, файл не будет включен. | `hello.md`

| | *Не совпадает*

`README.md`

`docs/hello.md` | | | | `'*.md'`

`'!README.md'`

`README*` | Шаблоны проверяются последовательно. Шаблон, который отрицает предыдущий шаблон, будет повторно включать пути к файлам. | `hello.md`

`README.md`

`README.doc` |