Синтаксис рабочего процесса для GitHub Actions

Сведения о синтаксисе YAML для рабочих процессов

Файлы рабочего процесса используют синтаксис YAML и должны иметь расширение файла .yml или .yaml. Если вы не знакомы с YAML и хотите узнать больше, ознакомьтесь с разделом "Сведения о YAML" в минутах Y.

Файлы рабочего процесса необходимо хранить в каталоге .github/workflows репозитория.

name

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

run-name

Имя рабочего процесса, созданное из рабочего процесса. GitHub отображает название запуска рабочего процесса в списке запущенных рабочих процессов на вкладке «Действия» вашего репозитория. Если run-name пропущено или это только пробел, то название запуска устанавливается на информацию, специфичную для события, для запуска рабочего процесса. Например, для рабочего процесса, активированного событием push или событием, оно устанавливается как сообщение фиксации или pull_request название запроса на вытягивание.

Это значение может включать выражения и может ссылаться на github них и inputs контексты.

Пример run-name

run-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }}

on

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

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

Использование одного события

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

on: push

Использование нескольких событий

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

on: [push, fork]

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

Использование типов действий

Некоторые события имеют типы действий, позволяющие лучше контролировать выполнение рабочего процесса. Используйте on.<event_name>.types для определения типа действия для события, которое активирует запуск рабочего процесса.

Например, событие issue_comment имеет типы действий created, edited и deleted. Если рабочий процесс активируется в событии label, он будет выполняться при создании, изменении или удалении метки. Если указать тип действия created для события label, рабочий процесс будет запускаться при создании метки, но не при изменении или удалении метки.

on:
  label:
    types:
      - created

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

on:
  issues:
    types:
      - opened
      - labeled

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

Использование фильтров

Некоторые события имеют фильтры, позволяющие лучше контролировать выполнение рабочего процесса.

Например, событие push имеет фильтр branches, из-за которого рабочий процесс выполняется только при отправке в ветвь, которая соответствует фильтру branches, а не при любой отправке.

on:
  push:
    branches:
      - main
      - 'releases/**'

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

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

Например, рабочий процесс со следующим значением on будет выполняться в следующих случаях:

• создание метки;
• отправка в ветвь main в репозитории;
• отправка в ветвь с поддержкой GitHub Pages.

on:
  label:
    types:
      - created
  push:
    branches:
      - main
  page_build:

on.<event_name>.types

Используйте on.<event_name>.types для определения типа действия для события, которое активирует выполнение рабочего процесса. Большинство событий GitHub активируются несколькими типами действий. Например, label активируется, если метка имеет значение created, edited или deleted. Ключевое слово types позволяет сузить действие, которое приводит к выполнению рабочего процесса. Если только один тип действия активирует событие веб-перехватчика, ключевое слово types не требуется.

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

on:
  label:
    types: [created, edited]

on.<pull_request|pull_request_target>.<branches|branches-ignore>

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

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

Если вы определили и branches/branches-ignore, и paths/paths-ignore, рабочий процесс будет запускаться только в случае, если выполнены оба фильтра.

Ключевые слова branches и branches-ignore принимают стандартные маски, использующие такие символы, как *, **, +, ?, ! и другие, чтобы соответствовать нескольким именам ветвей. Если имя содержит любой из этих символов и требуется буквальное совпадение, необходимо экранировать каждый из этих специальных символов с помощью \. Дополнительные сведения о шаблонах глобов см. в разделе AUTOTITLE.

Пример: включение ветвей

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

• ветви с именем main (refs/heads/main);
• ветви с именем mona/octocat (refs/heads/mona/octocat);
• ветви, имя которой начинается с releases/, например releases/10 (refs/heads/releases/10);

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches:
      - main
      - 'mona/octocat'
      - 'releases/**'

Не следует использовать фильтрацию пути или ветви, чтобы пропустить выполнение рабочего процесса, если рабочий процесс необходим для передачи перед слиянием. Дополнительные сведения см. в разделе [AUTOTITLE и Пропуск запусков рабочих процессов](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging).

Если рабочий процесс пропускается из-за фильтрации ветвей, фильтрации путей или сообщения фиксации, то проверки, связанные с этим рабочим процессом, останутся в состоянии "Ожидание". Запрос на включение внесенных изменений, требующий успешной проверки, будет заблокирован при слиянии.

Пример исключения ветвей

В случае соответствия шаблона branches-ignore рабочий процесс не будет выполняться. Шаблоны, определенные в branches-ignore, оцениваются по имени ссылки Git. Например, указанный ниже рабочий процесс будет выполняться всякий раз, когда происходит событие pull_request, если при этом запрос на вытягивание не нацелен на:

• ветви с именем mona/octocat (refs/heads/mona/octocat);
• ветви, имя которой соответствует releases/**-alpha, например releases/beta/3-alpha (refs/heads/releases/beta/3-alpha);

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches-ignore:
      - 'mona/octocat'
      - 'releases/**-alpha'

Пример: включение и исключение ветвей

Нельзя использовать branches и branches-ignore для фильтрации одного и того же события в одном рабочем процессе. Если вам нужно с помощью шаблонов одновременно включить и исключить имена ветвей для одного события, используйте фильтр branches с символом !, чтобы указать, какие ветви следует исключить.

Если вы определяете ветвь с символом !, необходимо также определить по крайней мере одну ветвь без символа !. Если вы хотите только исключить ветви, используйте вместо этого branches-ignore.

Порядок определения шаблонов имеет значение.

• Соответствующий отрицательный шаблон (с префиксом !) после положительного совпадения исключает ссылку Git.
• Соответствующий положительный шаблон после отрицательного совпадения снова включает ссылку Git.

Указанный ниже рабочий процесс будет выполняться на событиях pull_request для запросов на вытягивание, нацеленных на releases/10 или releases/beta/mona, но не для запросов на вытягивание, нацеленных на releases/10-alpha или releases/beta/3-alpha, потому что отрицательный шаблон !releases/**-alpha соответствует положительному шаблону.

on:
  pull_request:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

on.push.<branches|tags|branches-ignore|tags-ignore>

При использовании события push можно настроить выполнение рабочего процесса в определенных ветвях или тегах.

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

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

Если вы определяете только или branches``branches-ignore/толькоtags/tags-ignore, рабочий процесс не будет выполняться для событий, влияющих на неопределенную ссылку на Git. Если определить ни одно tags/tags-ignore илиbranches/branches-ignore, рабочий процесс будет выполняться для событий, влияющих на ветви или теги. Если вы определили и branches/branches-ignore, и paths/paths-ignore, рабочий процесс будет запускаться только в случае, если выполнены оба фильтра.

Ключевые слова branches, branches-ignore, tagsи tags-ignore принимают стандартные маски, использующие такие символы, как *, **, +, ?, ! и другие, для сопоставления нескольких имен ветвей или тегов. Если имя содержит любой из этих символов, и требуется буквальное совпадение, необходимо экранировать каждый из этих специальных символов с помощью \. Дополнительные сведения о шаблонах глобов см. в разделе AUTOTITLE.

Пример. Включение ветвей и тегов

Шаблоны, определенные в branches и tags, применяются для имени ссылки Git. Например, следующий рабочий процесс будет выполняться всякий раз, когда событие push происходит в:

• ветви с именем main (refs/heads/main);
• ветви с именем mona/octocat (refs/heads/mona/octocat);
• ветви, имя которой начинается с releases/, например releases/10 (refs/heads/releases/10);
• теге с именем v2 (refs/tags/v2);
• теге, имя которого начинается с v1., например v1.9.1 (refs/tags/v1.9.1).

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches:
      - main
      - 'mona/octocat'
      - 'releases/**'
    # Sequence of patterns matched against refs/tags
    tags:
      - v2
      - v1.*

Пример. Исключение ветвей и тегов

Если шаблон соответствует шаблону branches-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).

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.

on:
  push:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

on.<push|pull_request|pull_request_target>.<paths|paths-ignore>

При использовании событий push и pull_request можно настроить запускаемый рабочий процесс в зависимости от того, какие пути к файлам изменяются. Фильтры путей не оцениваются при отправке тегов.

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

Если вы определили и branches/branches-ignore, и paths/paths-ignore, рабочий процесс будет запускаться только в случае, если выполнены оба фильтра.

Ключевые слова paths и paths-ignore принимают стандартные маски, в которых для соответствия нескольким именам путей используются подстановочные знаки * и **. Дополнительные сведения см. в разделе AUTOTITLE.

Пример. Включение путей

Если хотя бы один путь соответствует шаблону в фильтре paths, рабочий процесс запускается. Например, приведенный ниже рабочий процесс будет выполняться при каждой отправке файла JavaScript (.js).

on:
  push:
    paths:
      - '**.js'

Не следует использовать фильтрацию пути или ветви, чтобы пропустить выполнение рабочего процесса, если рабочий процесс необходим для передачи перед слиянием. Дополнительные сведения см. в разделе [AUTOTITLE и Пропуск запусков рабочих процессов](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging).

Если рабочий процесс пропускается из-за фильтрации путей, фильтрации ветвей или сообщения фиксации, то проверки, связанные с этим рабочим процессом, останутся в состоянии "Ожидание". Запрос на включение внесенных изменений, требующий успешной проверки, будет заблокирован при слиянии.

Пример. Исключение путей

Если все имена путей соответствуют шаблонам в paths-ignore, рабочий процесс не запускается. Если хотя бы одно имя пути не соответствует шаблонам в paths-ignore, рабочий процесс запускается.

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

on:
  push:
    paths-ignore:
      - 'docs/**'

Пример. Включение и исключение путей

Нельзя использовать paths и paths-ignore для фильтрации одного и того же события в одном рабочем процессе. Если вы хотите включить и исключить шаблоны путей для одного события, используйте paths префикс фильтра с ! символом, чтобы указать, какие пути следует исключить.

Если вы определяете путь с символом !, необходимо также определить по крайней мере один путь без символа !. Если вы хотите только исключить пути, используйте вместо этого paths-ignore.

Порядок определения paths шаблонов имеет значение:

• Соответствующий отрицательный шаблон (с префиксом !) после положительного совпадения исключает путь.
• Соответствующий положительный шаблон после отрицательного совпадения снова включает путь.

Этот пример запускается каждый раз, когда событие push включает файл в каталоге sub-project или его подкаталогах, но не в каталоге sub-project/docs. Например, принудительная отправка с изменением sub-project/index.js или sub-project/src/index.js запустит выполнение рабочего процесса, но принудительная отправка, изменяющая только sub-project/docs/readme.md, не запустит его.

on:
  push:
    paths:
      - 'sub-project/**'
      - '!sub-project/docs/**'

Сравнение различий в GIT

Фильтр определяет, должен ли запускаться рабочий процесс, оценивая измененные файлы и проверяя их по списку paths-ignore или paths. Если измененных файлов нет, рабочий процесс не запускается.

GitHub создает список измененных файлов, используя различия с двумя точками для push-уведомлений и с тремя точками — для запросов на вытягивание.

• Запросы на вытягивание. Различия с тремя точками — это сравнение последней версией тематической ветки с фиксацией, в которой тематическая ветка была в последний раз синхронизирована с основной ветвью.
• Отправки в существующие ветви. Различие с двумя точками — это сравнение головных и базовых значений SHA непосредственно друг с другом.
• Отправки в новые ветви. Различие с двумя точками в сравнении с родителем предка самой глубокой отправленной фиксации.

Дополнительные сведения см. в разделе Сравнение ветвей в запросе на вытягивание.

on.schedule

С помощью on.schedule можно определить расписание рабочих процессов.

Используйте синтаксис POSIX cron для планирования рабочих процессов в определённое время. По умолчанию запланированные рабочие процессы работают в UTC. Вы можете опционально указать часовой пояс с помощью строки часового пояса IANA , чтобы планировать с учётом часового пояса. Запланированные рабочие процессы выполняются в последней фиксации на ветвь по умолчанию. Самый короткий интервал, с которым можно запускать запланированные рабочие процессы — 5 минут.

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

┌───────────── 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)
│ │ │ │ │
* * * * *

Эти операторы можно использовать в любом из пяти полей:

          `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 каждый понедельник по пятницу:

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 шаг в понедельник и среду.

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 разделе События, инициирующие рабочие процессы.

on.workflow_call

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

on.workflow_call.inputs

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

Помимо доступных стандартных входных параметров on.workflow_call.inputs требует параметр type. Дополнительные сведения см. в разделе on.workflow_call.inputs.<input_id>.type.

Если параметр default не задан, значение по умолчанию для входных данных — false для логического значения, 0 для числа и "" для строки.

В вызываемом рабочем процессе можно использовать контекст inputs для ссылки на входные данные. Дополнительные сведения см. в разделе Справочник по контекстам.

Если вызывающий рабочий процесс передает входные данные, которые не указаны в вызываемом рабочем процессе, это приведет к ошибке.

Пример on.workflow_call.inputs

on:
  workflow_call:
    inputs:
      username:
        description: 'A username passed from the caller workflow'
        default: 'john-doe'
        required: false
        type: string

jobs:
  print-username:
    runs-on: ubuntu-latest

    steps:
      - name: Print the input name to STDOUT
        run: echo The username is ${{ inputs.username }}

Дополнительные сведения см. в разделе Повторное использование рабочих процессов.

on.workflow_call.inputs.<input_id>.type

Требуется, если входные данные определены для ключевого слова on.workflow_call. Значение этого параметра — строка, указывающая тип входных данных. Должен иметь значение boolean, number или string.

on.workflow_call.outputs

Карта выходных данных для вызываемого рабочего процесса. Выходные данные вызываемого рабочего процесса доступны для всех нижестоящих заданий в рабочем процессе вызывающего объекта. У каждых выходных данных есть идентификатор, необязательный description, и value. Для value необходимо задать значение выходных данных из задания в рамках вызываемого рабочего процесса.

В приведенном ниже примере для этого многократно используемого рабочего процесса определяются два набора выходных данных: workflow_output1 и workflow_output2. Они сопоставляются с выходными данными job_output1 и job_output2 из вызываемого заданияmy_job.

Пример on.workflow_call.outputs

on:
  workflow_call:
    # Map the workflow outputs to job outputs
    outputs:
      workflow_output1:
        description: "The first job output"
        value: ${{ jobs.my_job.outputs.job_output1 }}
      workflow_output2:
        description: "The second job output"
        value: ${{ jobs.my_job.outputs.job_output2 }}

Сведения о том, как ссылаться на выходные данные задания, см. в разделе jobs.<job_id>.outputs. Дополнительные сведения см. в разделе Повторное использование рабочих процессов.

on.workflow_call.secrets

Карта секретов, которые можно использовать в вызываемом рабочем процессе.

В вызываемом рабочем процессе можно использовать контекст secrets для ссылки на секрет.

Если вызывающий рабочий процесс передает секрет, который не указан в вызываемом рабочем процессе, это приведет к ошибке.

Пример on.workflow_call.secrets

on:
  workflow_call:
    secrets:
      access-token:
        description: 'A token passed from the caller workflow'
        required: false

jobs:

  pass-secret-to-action:
    runs-on: ubuntu-latest
    steps:
    # passing the secret to an action
      - name: Pass the received secret to an action
        uses: ./.github/actions/my-action
        with:
          token: ${{ secrets.access-token }}

  # passing the secret to a nested reusable workflow
  pass-secret-to-workflow:
    uses: ./.github/workflows/my-workflow
    secrets:
       token: ${{ secrets.access-token }}

on.workflow_call.secrets.<secret_id>

Строковый идентификатор, связанный с секретом.

on.workflow_call.secrets.<secret_id>.required

Логическое значение, указывающее, должен ли быть предоставлен секрет.

on.workflow_run.<branches|branches-ignore>

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

В фильтрах branches и branches-ignore можно использовать стандартные маски с такими символами, как *, **, +, ?, ! и другие, для сопоставления нескольких имен ветвей. Если имя содержит любой из этих символов, и требуется буквальное совпадение, необходимо экранировать каждый из этих специальных символов с помощью \. Дополнительные сведения о шаблонах глобов см. в разделе AUTOTITLE.

Например, рабочий процесс со следующим триггером будет выполняться, только если рабочий процесс с именем Build выполняется в ветви, имя которой начинается с releases/.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'

Рабочий процесс со следующим триггером будет выполняться, только если рабочий процесс с именем Build выполняется в ветви с именем отличным от canary.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches-ignore:
      - "canary"

Для одного и того же события в рабочем процессе нельзя использовать фильтры branches и branches-ignore одновременно. Если вам нужно с помощью шаблонов одновременно включить и исключить имена ветвей для одного события, используйте фильтр branches с символом !, чтобы указать, какие ветви следует исключить.

Порядок определения шаблонов имеет значение.

• Если после включающего шаблона идет исключающий (с префиксом !) и найдена ветвь, соответствующая им обоим, такая ветвь исключается.
• Если после исключающего шаблона идет включающий, ветвь, соответствующая им обоим, снова включается.

Например, рабочий процесс со следующим триггером будет выполняться, если рабочий процесс с именем Build выполняется в ветви с именем releases/10 или releases/beta/mona, но не в ветви releases/10-alpha, releases/beta/3-alpha или main.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

on.workflow_dispatch

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

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

on.workflow_dispatch.inputs

Активированный рабочий процесс получает входные данные в контексте inputs. Дополнительные сведения см. в разделе "Контексты".

Пример on.workflow_dispatch.inputs

on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning'
        type: choice
        options:
          - info
          - warning
          - debug
      print_tags:
        description: 'True to print to STDOUT'
        required: true
        type: boolean
      tags:
        description: 'Test scenario tags'
        required: true
        type: string
      environment:
        description: 'Environment to run tests against'
        type: environment
        required: true

jobs:
  print-tag:
    runs-on: ubuntu-latest
    if: ${{ inputs.print_tags }} 
    steps:
      - name: Print the input tag to STDOUT
        run: echo  The tags are ${{ inputs.tags }} 

on.workflow_dispatch.inputs.<input_id>.required

Логическое значение, указывающее, нужно ли предоставлять входные данные.

on.workflow_dispatch.inputs.<input_id>.type

Значение этого параметра — строка, указывающая тип входных данных. Это должно быть одно из следующих: boolean, choice``number``environment или .string

permissions

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

          `permissions` можно использовать в качестве ключа верхнего уровня для применения ко всем заданиям в рабочем процессе или в конкретных заданиях. При добавлении ключа `permissions` в конкретном задании указанные права доступа получают все действия и команды выполнения в этом задании, использующие `GITHUB_TOKEN`. Дополнительные сведения см. в разделе [`jobs.<job_id>.permissions`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions).

Владельцы организации или enterprise могут ограничить доступ на запись на GITHUB_TOKEN уровне репозитория. Дополнительные сведения см. в разделе Отключение или ограничение GitHub Actions для вашей организации и Применение политик для GitHub Actions в вашем предприятии.

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

Для каждого из доступных разрешений, показанных в таблице ниже, можно назначить один из уровней доступа: read (если применимо), writeили none. write включает в себя read. Если указать доступ для любого из этих разрешений, то для всех этих разрешений задано noneзначение .

Доступные разрешения и подробные сведения о том, что позволяет выполнять действие:

Определение доступа для GITHUB_TOKEN областей

Вы можете определить доступ, который GITHUB_TOKEN будет разрешен, указав readили write``none как значение доступных разрешений в permissions ключе.

permissions:
  actions: read|write|none
  checks: read|write|none
  contents: read|write|none
  deployments: read|write|none
  issues: read|write|none
  discussions: read|write|none
  packages: read|write|none
  pages: read|write|none
  pull-requests: read|write|none
  security-events: read|write|none
  statuses: read|write|none

Если указать доступ для любого из этих разрешений, то для всех этих разрешений задано noneзначение .

Для определения одного из read-all``write-all доступных разрешений можно использовать следующий синтаксис:

permissions: read-all

permissions: write-all

Для отключения разрешений для всех доступных разрешений можно использовать следующий синтаксис:

permissions: {}

Изменение разрешений в вилку репозитория

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

Как вычисляются разрешения для задания рабочего процесса

Изначально в качестве разрешений для GITHUB_TOKEN задаются параметры по умолчанию для предприятия, организации или репозитория. Если на любом из этих уровней по умолчанию заданы ограниченные разрешения, они будут применяться к соответствующим репозиториям. Например, если выбрать в качестве значения по умолчанию на уровне организации ограниченные разрешения, все репозитории в этой организации будут использовать в качестве значения по умолчанию ограниченные разрешения. Затем разрешения корректируются на основе любой конфигурации в файле рабочего процесса: сначала на уровне рабочего процесса, а затем на уровне задания. Наконец, если рабочий процесс был запущен событием pull request, отличным pull_request_target от форкированного репозитория, и токены Send write to workflows из настройки pull requests не выбраны, права на запись изменяются на только чтение.

          `GITHUB_TOKEN` Настройка разрешений для всех заданий в рабочем процессе

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

Пример. Настройка GITHUB_TOKEN разрешений для всего рабочего процесса

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

name: "My workflow"

on: [ push ]

permissions: read-all

jobs:
  ...

          `permissions` Использование ключа для вилированных репозиториев

Ключ можно использовать permissions для добавления и удаления read разрешений для вилированных репозиториев, но обычно невозможно предоставить write доступ. Исключение из этого поведения — когда администратор-пользователь выбрал токены «Отправить токены записи в рабочие процессы» из опции pull requests в GitHub Actions настройках. Дополнительные сведения см. в разделе Управление настройками GitHub Actions для репозитория.

Права на запуски рабочих процессов, вызываемые Dependabot

Рабочий процесс запускается с помощью запросов на вытягивание Dependabot, как если бы они выполнялись из вилированного репозитория и поэтому используют только GITHUB_TOKENдля чтения. Этот рабочий процесс не может получить доступ к секретам. Сведения о стратегиях защиты этих рабочих процессов см. в разделе Справочник по безопасному использованию.

env

Переменные map , доступные для шагов всех заданий в рабочем процессе. Можно также задать переменные, доступные только для шагов одного задания или на одном шаге. Дополнительные сведения см. в разделах jobs.<job_id>.env и jobs.<job_id>.steps[*].env.

Переменные на схеме env не могут быть определены с точки зрения других переменных на карте.

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

Пример env

env:
  SERVER: production

defaults

Используйте defaults для создания map с параметрами по умолчанию, которые будут применяться ко всем заданиям в рабочем процессе. Можно также указать параметры по умолчанию, доступные только для задания. Дополнительные сведения см. в разделе jobs.<job_id>.defaults.

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

defaults.run

Можно использовать defaults.run для указания параметров по умолчанию shell и working-directory для всех этапов run в рабочем процессе. Можно также указать параметры по умолчанию для run, доступные только для задания. Дополнительные сведения см. в разделе jobs.<job_id>.defaults.run. В этом ключевом слове нельзя использовать контексты или выражения.

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

Пример. Указание оболочки по умолчанию и рабочего каталога

defaults:
  run:
    shell: bash
    working-directory: ./scripts

defaults.run.shell

Используется shell для определения shell шага. Это ключевое слово может ссылаться на несколько контекстов. Дополнительные сведения см. в разделе "Контексты".

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

defaults.run.working-directory

Используется working-directory для определения рабочего каталога для shell шага. Это ключевое слово может ссылаться на несколько контекстов. Дополнительные сведения см. в разделе "Контексты".

concurrency

Используйте concurrency, чтобы одновременно могли выполняться только одно задание или один процесс с использованием той же группы параллелизма. Группа параллелизма может представлять собой любую строку или выражение. Выражение может использовать [inputs``github[](/actions/learn-github-actions/contexts#inputs-context) ](/actions/learn-github-actions/contexts#vars-context)varsтолько контекст и контексты. Дополнительные сведения о выражениях см. в разделе Оценка выражений в рабочих процессах и действиях.

Также можно задать concurrency на уровне задания. Дополнительные сведения см. в разделе jobs.<job_id>.concurrency.

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

Чтобы также отменить задание или рабочий процесс, которые сейчас выполняются в той же группе параллелизма, укажите cancel-in-progress: true. Чтобы условно отменить выполняемые в настоящее время задания или рабочие процессы в той же группе параллелизма, можно указать cancel-in-progress как выражение с любым из контекстов разрешенного выражения.

Пример. Использование параллелизма и поведения по умолчанию

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

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

on:
  push:
    branches:
      - main

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Кроме того, можно ограничить параллелизм заданий в рабочем процессе с помощью concurrency ключевого слова на уровне задания:

on:
  push:
    branches:
      - main

jobs:
  job-1:
    runs-on: ubuntu-latest
    concurrency:
      group: example-group
      cancel-in-progress: true

Пример: группы параллелизма

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

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

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

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

В этом примере job-1 является частью группы параллелизма с именем staging_environment. Это означает, что если запускается новый запуск job-1 , все запуски того же задания в staging_environment группе параллелизма, которые уже выполняются, будут отменены.

jobs:
  job-1:
    runs-on: ubuntu-latest
    concurrency:
      group: staging_environment
      cancel-in-progress: true

Кроме того, использование динамического выражения, например concurrency: ci-${{ github.ref }} в рабочем процессе, означает, что рабочий процесс или задание будет частью группы ci- параллелизма, за которой следует ссылка на ветвь или тег, активировавший рабочий процесс. В этом примере, если новая фиксация отправляется в основную ветвь, пока предыдущий запуск по-прежнему выполняется, предыдущий запуск будет отменен, а новый будет запущен:

on:
  push:
    branches:
      - main

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

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

Чтобы использовать параллелизм для отмены любого выполняемого задания или запуска в GitHub Actions, можно использовать concurrency ключ с параметром cancel-in-progress :true

concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true

Обратите внимание, что в этом примере без определения определенной группы параллелизма GitHub Actions отменит выполнение задания или рабочего процесса.

Пример. Использование резервного значения

Если вы создаете имя группы со свойством, определенным только для определенных событий, можно использовать резервное значение. Например, github.head_ref определяется только для событий pull_request. Если рабочий процесс реагирует на другие события в дополнение к событиям pull_request, необходимо предоставить резервное значение, чтобы избежать синтаксической ошибки. Следующая группа параллелизма отменяет выполняемые задания или запуски только в событиях pull_request. Если параметр github.head_ref не определен, группа параллелизма перейдет к идентификатору запуска, который будет гарантированно заданным и уникальным.

concurrency:
  group: ${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

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

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

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

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Пример. Отмена только выполняемых заданий в определенных ветвях

Если вы хотите отменить выполняемые задания в определенных ветвях, но не на других, можно использовать условные выражения с cancel-in-progress. Например, это можно сделать, если вы хотите отменить выполняемые задания в ветвях разработки, но не в ветвях выпуска.

Чтобы отменить выполнение только выполняемых запусков одного рабочего процесса, если он не запущен в ветви выпуска, можно задать cancel-in-progress выражение, аналогичное следующему:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ !contains(github.ref, 'release/')}}

В этом примере несколько push-уведомлений в release/1.2.3 ветвь не отменяют выполняемые запуски. Отправка в другую ветвь, например main, отменяет выполняемые запуски.

jobs

Запуск рабочего процесса состоит из одного или нескольких jobs, которые по умолчанию выполняются параллельно. Для последовательного выполнения заданий можно определить зависимости в других заданиях с помощью ключевого слова jobs.<job_id>.needs.

Каждое задание выполняется в среде средства выполнения тестов, указанной в параметре runs-on.

Вы можете выполнять неограниченное количество заданий, если вы не превышаете лимиты по использованию рабочих процессов. Дополнительные сведения см. в разделе [AUTOTITLE для GitHubразмещенных в среде runner и Выставление счетов и использование](/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners) для ограничения использования локального runner.

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

jobs.<job_id>

Используйте jobs.<job_id>, чтобы назначить заданию уникальный идентификатор. Ключ job_id представляет собой строку, а значение ключа представляет собой карту данных конфигурации задания. Необходимо заменить <job_id> строкой, уникальной для объекта jobs. <job_id> должен начинаться с буквы или _ и может включать только буквенно-цифровые символы - или _.

Пример. Создание заданий

В этом примере были созданы два задания, и их job_id равны my_first_job и my_second_job.

jobs:
  my_first_job:
    name: My first job
  my_second_job:
    name: My second job

jobs.<job_id>.name

Используйте jobs.<job_id>.name для присвоения имени заданию, которое отображается в пользовательском интерфейсе GitHub.

jobs.<job_id>.permissions

Для определенного задания jobs.<job_id>.permissions можно использовать для изменения разрешений по умолчанию, предоставленных GITHUB_TOKEN, при необходимости добавляя или удаляя права доступа, чтобы разрешить только минимальный требуемый доступ. Дополнительные сведения см. в разделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах.

Указав разрешение в определении задания, при необходимости можно настроить для каждого задания другой набор разрешений для GITHUB_TOKEN. Кроме того, можно указать разрешения для всех заданий в рабочем процессе. Сведения об определении разрешений на уровне рабочего процесса см. в разделе permissions.

Для каждого из доступных разрешений, показанных в таблице ниже, можно назначить один из уровней доступа: read (если применимо), writeили none. write включает в себя read. Если указать доступ для любого из этих разрешений, то для всех этих разрешений задано noneзначение .

Доступные разрешения и подробные сведения о том, что позволяет выполнять действие:

Определение доступа для GITHUB_TOKEN областей

Вы можете определить доступ, который GITHUB_TOKEN будет разрешен, указав readили write``none как значение доступных разрешений в permissions ключе.

permissions:
  actions: read|write|none
  checks: read|write|none
  contents: read|write|none
  deployments: read|write|none
  issues: read|write|none
  discussions: read|write|none
  packages: read|write|none
  pages: read|write|none
  pull-requests: read|write|none
  security-events: read|write|none
  statuses: read|write|none

Если указать доступ для любого из этих разрешений, то для всех этих разрешений задано noneзначение .

Для определения одного из read-all``write-all доступных разрешений можно использовать следующий синтаксис:

permissions: read-all

permissions: write-all

Для отключения разрешений для всех доступных разрешений можно использовать следующий синтаксис:

permissions: {}

Изменение разрешений в вилку репозитория

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

Пример. Настройка GITHUB_TOKEN разрешений для одного задания в рабочем процессе

В этом примере показаны разрешения, заданные для задания GITHUB_TOKEN, которое будет применяться только к заданию с именем stale. Доступ на запись предоставляется для issues разрешений и pull-requests разрешений. Все остальные разрешения не будут иметь доступа.

jobs:
  stale:
    runs-on: ubuntu-latest

    permissions:
      issues: write
      pull-requests: write

    steps:
      - uses: actions/stale@v10

jobs.<job_id>.needs

Используйте jobs.<job_id>.needs для определения всех заданий, которые должны быть успешно завершены перед выполнением этого задания. Это может быть строка или массив строк. Если задание завершается ошибкой или пропускается, все задания, необходимые для него, пропускаются, если задания не используют условное выражение, которое приводит к продолжению задания. Если выполнение содержит ряд заданий, которые нуждаются друг в другом, сбой или пропуск применяется ко всем заданиям в цепочке зависимостей из точки сбоя или пропускания. Если вы хотите выполнить задание, даже если задание зависит от не удалось, используйте условное always() выражение в jobs.<job_id>.if.

Пример. Необходимо успешное выполнение зависимых заданий

jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]

В этом примере задание job1 должно успешно завершить работу перед началом задания job2, а задание job3 ожидает завершения заданий job1 и job2.

Задания в этом примере выполняются последовательно:

1. job1
2. job2
3. job3

Пример. Успешное выполнение зависимых заданий не требуется

jobs:
  job1:
  job2:
    needs: job1
  job3:
    if: ${{ always() }}
    needs: [job1, job2]

В этом примере в задании job3 используется условное выражение always(), чтобы оно всегда выполнялось после завершения выполнения заданий job1 и job2, независимо от того, завершились ли они успешно. Дополнительные сведения см. в разделе Оценка выражений в рабочих процессах и действиях.

jobs.<job_id>.if

Условное выражение jobs.<job_id>.if можно использовать для предотвращения выполнения задания, если условие не выполняется. Для создания условного выражения можно использовать любой поддерживаемый контекст и любое выражение. Дополнительные сведения о том, какие контексты поддерживаются в этом ключе, см. в разделе Справочник по контекстам.

При использовании выражений в условном if режиме можно, при необходимости, опустить синтаксис выражения ${{ }}, так как GitHub Actions автоматически вычисляет условное if выражение как выражение. Однако это исключение не применяется везде.

Всегда следует использовать синтаксис выражения ${{ }}концевого выражения %} или экранировать с '', ""либо () когда выражение начинается с !, так как ! зарезервировано нотация в формате YAML. Например:

{% raw %}

if: ${{ ! startsWith(github.ref, 'refs/tags/') }}

Дополнительные сведения см. в разделе Оценка выражений в рабочих процессах и действиях.

Пример. Выполнение задания только для определенного репозитория

В этом примере используется if для управления выполнением задания production-deploy. Оно будет выполняться только в том случае, если репозиторий имеет имя octo-repo-prod и находится в организации octo-org. В противном случае задание будет отмечено как пропущенное.

name: example-workflow
on: [push]
jobs:
  production-deploy:
    if: github.repository == 'octo-org/octo-repo-prod'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats

name: example-workflow
on: [push]
jobs:
  production-deploy:
    if: github.repository == 'octo-org/octo-repo-prod'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats

jobs.<job_id>.runs-on

Используйте jobs.<job_id>.runs-on для определения типа компьютера, на котором будет запускаться задание.

• Конечный компьютер может быть локальным runner.

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

• Вы можете предоставить следующие возможности runs-on :

  • Одна строка
  • Одна переменная, содержащая строку
  • Массив строк, переменных, содержащих строки, или сочетание обоих
  • key: value Пара с помощью клавиш или labels ключей group

• При указании массива строк или переменных рабочий процесс будет выполняться на любом средстве выполнения, который соответствует всем указанным runs-on значениям. Например, здесь задание будет выполняться только на локальном runner с метками linuxиx64``gpu:

  runs-on: [self-hosted, linux, x64, gpu]
  

  Дополнительные сведения см. в разделе "Выбор локальных средств выполнения".

• Строки и переменные можно смешивать в массиве. Например:

  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.<job_id>.strategy.

Выбор GitHubведущих бегунов

Выбор локальных средств выполнения тестов

Чтобы указать локальное средство выполнения тестов для задания, настройте runs-on в файле рабочего процесса, используя метки локального средства выполнения тестов.

У локальных модулей выполнения может быть self-hosted метка. При настройке локального runner по умолчанию мы будем включать метку self-hosted. Вы можете передать --no-default-labels флаг, чтобы предотвратить применение локальной метки. Метки можно использовать для создания параметров целевого назначения для средств выполнения, таких как операционная система или архитектура, мы рекомендуем предоставить массив меток, начинающихся с self-hosted (это должно быть указано сначала), а затем включить дополнительные метки по мере необходимости. При указании массива меток задания будут помещены в очередь в средства выполнения тестов, которые имеют все указанные метки.

Пример: использование меток для выбора средства выполнения тестов

runs-on: [self-hosted, linux]

Дополнительные сведения см. в разделе [AUTOTITLE и Локальные средства выполнения тестов](/actions/hosting-your-own-runners/managing-self-hosted-runners/using-self-hosted-runners-in-a-workflow).

Выбор бегуна в группе

Вы можете использовать runs-on для целевых групп runner, чтобы задание выполнялось на любом средстве выполнения, являющегося членом этой группы. Для более детального управления можно также объединить группы runner с метками.

Пример. Использование групп для управления выполнением заданий

В этом примере средства запуска Ubuntu добавлены в группу с именем ubuntu-runners. Ключ runs-on отправляет задание любому доступному ubuntu-runners средству выполнения в группе:

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on: 
      group: ubuntu-runners
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Пример. Объединение групп и меток

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

В этом примере вызываемая ubuntu-runners группа runner заполняется средствами запуска Ubuntu, которые также были назначены меткой ubuntu-24.04-16core. Ключ runs-on объединяется group и labels таким образом, чтобы задание перенаправлялось на любой доступный runner в группе, которая также имеет соответствующую метку:

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on:
      group: ubuntu-runners
      labels: ubuntu-24.04-16core
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        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/:

runs-on:
  group: org/my-group
  labels: [ self-hosted, label-1 ]

Использование среды ent/:

runs-on:
  group: ent/my-group
  labels: [ self-hosted, label-1 ]

jobs.<job_id>.environment

Используется jobs.<job_id>.environment для определения среды, на которую ссылается задание.

Вы можете указать среду в виде только имени среды name или в виде объекта среды с name и url. URL-адрес сопоставляется с environment_url в API развертываний. Дополнительные сведения об API развертываний см. в разделе Конечные точки REST API для репозиториев.

Пример. Использование только имени среды

environment: staging_environment

Пример. Использование имени среды и URL-адреса

environment:
  name: production_environment
  url: https://github.com

Значение url может быть выражением. Контексты разрешенных выражений: github, [[matrix[[strategyenv](/actions/learn-github-actions/contexts#env-context)runner``inputsvars``needs](/actions/learn-github-actions/contexts#vars-context)[](/actions/learn-github-actions/contexts#runner-context)](/actions/learn-github-actions/contexts#matrix-context)job](/actions/learn-github-actions/contexts#needs-context)и .steps Дополнительные сведения о выражениях см. в разделе Оценка выражений в рабочих процессах и действиях.

Пример. Использование выходных данных в качестве URL-адреса

environment:
  name: production_environment
  url: ${{ steps.step_id.outputs.url_output }}

Значение name может быть выражением. Контексты разрешенных выражений: github,inputs , vars,needs ,strategy и .matrix Дополнительные сведения о выражениях см. в разделе Оценка выражений в рабочих процессах и действиях.

Пример. Использование выражения в качестве имени среды

environment:
  name: ${{ github.ref_name }}

jobs.<job_id>.concurrency

Можно использовать jobs.<job_id>.concurrency, чтобы одновременно могли выполняться только одно задание или один процесс с использованием той же группы параллелизма. Группа параллелизма может представлять собой любую строку или выражение. Контексты разрешенных выражений: github,inputs , vars,needs ,strategy и .matrix Дополнительные сведения о выражениях см. в разделе Оценка выражений в рабочих процессах и действиях.

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

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

Чтобы также отменить задание или рабочий процесс, которые сейчас выполняются в той же группе параллелизма, укажите cancel-in-progress: true. Чтобы условно отменить выполняемые в настоящее время задания или рабочие процессы в той же группе параллелизма, можно указать cancel-in-progress как выражение с любым из контекстов разрешенного выражения.

Пример. Использование параллелизма и поведения по умолчанию

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

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

on:
  push:
    branches:
      - main

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Кроме того, можно ограничить параллелизм заданий в рабочем процессе с помощью concurrency ключевого слова на уровне задания:

on:
  push:
    branches:
      - main

jobs:
  job-1:
    runs-on: ubuntu-latest
    concurrency:
      group: example-group
      cancel-in-progress: true

Пример: группы параллелизма

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

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

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

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

В этом примере job-1 является частью группы параллелизма с именем staging_environment. Это означает, что если запускается новый запуск job-1 , все запуски того же задания в staging_environment группе параллелизма, которые уже выполняются, будут отменены.

jobs:
  job-1:
    runs-on: ubuntu-latest
    concurrency:
      group: staging_environment
      cancel-in-progress: true

Кроме того, использование динамического выражения, например concurrency: ci-${{ github.ref }} в рабочем процессе, означает, что рабочий процесс или задание будет частью группы ci- параллелизма, за которой следует ссылка на ветвь или тег, активировавший рабочий процесс. В этом примере, если новая фиксация отправляется в основную ветвь, пока предыдущий запуск по-прежнему выполняется, предыдущий запуск будет отменен, а новый будет запущен:

on:
  push:
    branches:
      - main

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

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

Чтобы использовать параллелизм для отмены любого выполняемого задания или запуска в GitHub Actions, можно использовать concurrency ключ с параметром cancel-in-progress :true

concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true

Обратите внимание, что в этом примере без определения определенной группы параллелизма GitHub Actions отменит выполнение задания или рабочего процесса.

Пример. Использование резервного значения

Если вы создаете имя группы со свойством, определенным только для определенных событий, можно использовать резервное значение. Например, github.head_ref определяется только для событий pull_request. Если рабочий процесс реагирует на другие события в дополнение к событиям pull_request, необходимо предоставить резервное значение, чтобы избежать синтаксической ошибки. Следующая группа параллелизма отменяет выполняемые задания или запуски только в событиях pull_request. Если параметр github.head_ref не определен, группа параллелизма перейдет к идентификатору запуска, который будет гарантированно заданным и уникальным.

concurrency:
  group: ${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

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

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

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

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Пример. Отмена только выполняемых заданий в определенных ветвях

Если вы хотите отменить выполняемые задания в определенных ветвях, но не на других, можно использовать условные выражения с cancel-in-progress. Например, это можно сделать, если вы хотите отменить выполняемые задания в ветвях разработки, но не в ветвях выпуска.

Чтобы отменить выполнение только выполняемых запусков одного рабочего процесса, если он не запущен в ветви выпуска, можно задать cancel-in-progress выражение, аналогичное следующему:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ !contains(github.ref, 'release/')}}

В этом примере несколько push-уведомлений в release/1.2.3 ветвь не отменяют выполняемые запуски. Отправка в другую ветвь, например main, отменяет выполняемые запуски.

jobs.<job_id>.outputs

Можно использовать jobs.<job_id>.outputs для создания map выходных данных для задания. Выходные данные задания доступны для всех подчиненных заданий, которые зависят от этого задания. Дополнительные сведения об определении зависимостей заданий см. в разделе jobs.<job_id>.needs.

Выходные данные могут составлять не более 1 МБ на задание. Общий объем выходных данных в выполнении рабочего процесса не может превышать 50 МБ. Размер приблизительный на основе кодировки UTF-16.

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

Если выходные данные пропущены, так как он может содержать секрет, появится следующее предупреждение: "Пропустить выходные данные {output.Key} , так как он может содержать секрет". Дополнительные сведения об обработке секретов см. в примере: маскирование и передача секрета между заданиями или рабочими процессами.

Чтобы применять выходные данные задания в зависимом задании, можно использовать контекст needs. Дополнительные сведения см. в разделе Справочник по контекстам.

Пример: определение выходных данных для задания

jobs:
  job1:
    runs-on: ubuntu-latest
    # Map a step output to a job output
    outputs:
      output1: ${{ steps.step1.outputs.test }}
      output2: ${{ steps.step2.outputs.test }}
    steps:
      - id: step1
        run: echo "test=hello" >> "$GITHUB_OUTPUT"
      - id: step2
        run: echo "test=world" >> "$GITHUB_OUTPUT"
  job2:
    runs-on: ubuntu-latest
    needs: job1
    steps:
      - env:
          OUTPUT1: ${{needs.job1.outputs.output1}}
          OUTPUT2: ${{needs.job1.outputs.output2}}
        run: echo "$OUTPUT1 $OUTPUT2"

Использование выходных данных задания в матрицном задании

Матрицы можно использовать для создания нескольких выходных данных разных имен. При использовании матрицы выходные данные заданий будут объединены из всех заданий внутри матрицы.

jobs:
  job1:
    runs-on: ubuntu-latest
    outputs:
      output_1: ${{ steps.gen_output.outputs.output_1 }}
      output_2: ${{ steps.gen_output.outputs.output_2 }}
      output_3: ${{ steps.gen_output.outputs.output_3 }}
    strategy:
      matrix:
        version: [1, 2, 3]
    steps:
      - name: Generate output
        id: gen_output
        run: |
          version="${{ matrix.version }}"
          echo "output_${version}=${version}" >> "$GITHUB_OUTPUT"
  job2:
    runs-on: ubuntu-latest
    needs: [job1]
    steps:
      # Will show
      # {
      #   "output_1": "1",
      #   "output_2": "2",
      #   "output_3": "3"
      # }
      - run: echo '${{ toJSON(needs.job1.outputs) }}'

jobs.<job_id>.env

Переменные map , доступные для всех шагов в задании. Можно задать переменные для всего рабочего процесса или отдельного шага. Дополнительные сведения см. в разделах env и jobs.<job_id>.steps[*].env.

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

Пример jobs.<job_id>.env

jobs:
  job1:
    env:
      FIRST_NAME: Mona

jobs.<job_id>.defaults

Используйте jobs.<job_id>.defaults для создания map с параметрами по умолчанию, которые будут применяться ко всем шагам задания. Вы также можете задать параметры по умолчанию для всего рабочего процесса. Дополнительные сведения см. в разделе defaults.

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

jobs.<job_id>.defaults.run

Использует jobs.<job_id>.defaults.run для предоставления параметры по умолчанию shell и working-directory для всех этапов run в задании.

Можно указать параметры по умолчанию shell и working-directory для всех этапов run в задании. Вы также можете задать параметры по умолчанию для run для всего рабочего процесса. Дополнительные сведения см. в разделе defaults.run.

Их можно переопределить на jobs.<job_id>.defaults.run уровнях и jobs.<job_id>.steps[*].run уровнях.

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

jobs.<job_id>.defaults.run.shell

Используется shell для определения shell шага. Это ключевое слово может ссылаться на несколько контекстов. Дополнительные сведения см. в разделе "Контексты".

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

jobs.<job_id>.defaults.run.working-directory

Используется working-directory для определения рабочего каталога для shell шага. Это ключевое слово может ссылаться на несколько контекстов. Дополнительные сведения см. в разделе "Контексты".

Пример. Настройка параметров этапа по умолчанию run для задания

jobs:
  job1:
    runs-on: ubuntu-latest
    defaults:
      run:
        shell: bash
        working-directory: ./scripts

jobs.<job_id>.steps

Задание содержит последовательность задач, называемых шагами (steps). Шаги могут выполнять команды, задачи установки или действия в репозитории, общедоступном репозитории или в реестре Docker. Не все шаги выполняют действия, но все действия выполняются как шаги. Каждый шаг выполняется в собственном процессе в среде средства выполнения и имеет доступ к рабочей области и файловой системе. Так как шаги выполняются в собственном процессе, изменения переменных среды не сохраняются между шагами. GitHub предоставляет встроенные шаги для организации и завершения работы.

          GitHub Отображается только первые 1000 проверок, однако вы можете выполнять неограниченное количество шагов, если находитесь в пределах лимитов использования рабочего процесса. Для получения дополнительной информации см. [AUTOTITLE](/actions/learn-github-actions/usage-limits-billing-and-administration) для GitHub-hosted runners и [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners) для самостоятельных ограничений использования бегунов.

Пример jobs.<job_id>.steps

name: Greeting from Mona

on: push

jobs:
  my-job:
    name: My Job
    runs-on: ubuntu-latest
    steps:
      - name: Print a greeting
        env:
          MY_VAR: Hi there! My name is
          FIRST_NAME: Mona
          MIDDLE_NAME: The
          LAST_NAME: Octocat
        run: |
          echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.

jobs.<job_id>.steps[*].id

Уникальный идентификатор шага. Вы можете использовать id для ссылки на шаг в контекстах. Дополнительные сведения см. в разделе Справочник по контекстам.

jobs.<job_id>.steps[*].if

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

          При использовании выражений в условном `if` режиме можно, при необходимости, опустить синтаксис выражения `${{ }}`, так как GitHub Actions автоматически вычисляет условное `if` выражение как выражение. Однако это исключение не применяется везде.
          
          Всегда следует использовать синтаксис выражения `${{ }}`концевого выражения %} или экранировать с `''`, `""`либо `()` когда выражение начинается с `!`, так как `!` зарезервировано нотация в формате YAML. Например:
          
          {% raw %}
          
          ```yaml
          if: ${{ ! startsWith(github.ref, 'refs/tags/') }}
          ```
          
           Для получения дополнительной информации см. [AUTOTITLE](/actions/learn-github-actions/expressions).

Пример. Использование контекстов

Этот шаг выполняется, только если типом события является pull_request, а действием — unassigned.

steps:
  - name: My first step
    if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}
    run: echo This event is a pull request that had an assignee removed.

Пример. Использование функций проверки состояния

          `my backup step` выполняется только при сбое предыдущего шага задания. Дополнительные сведения см. в разделе [AUTOTITLE](/actions/learn-github-actions/expressions#status-check-functions).

steps:
  - name: My first step
    uses: octo-org/action-name@main
  - name: My backup step
    if: ${{ failure() }}
    uses: actions/heroku@1.0.0

Пример. Использование секретов

На секреты нельзя напрямую ссылаться в условных выражениях if:. Вместо этого рекомендуется задать секреты в качестве переменных среды на уровне задания, а затем создать ссылки на переменные среды для условного выполнения шагов в задании.

Если секрет не установлен, возвращаемое значение выражения, ссылающегося на секрет (например ${{ secrets.SuperSecret }} , в примере), будет пустой строкой.

name: Run a step if a secret has been set
on: push
jobs:
  my-jobname:
    runs-on: ubuntu-latest
    env:
      super_secret: ${{ secrets.SuperSecret }}
    steps:
      - if: ${{ env.super_secret != '' }}
        run: echo 'This step will only run if the secret has a value set.'
      - if: ${{ env.super_secret == '' }}
        run: echo 'This step will only run if the secret does not have a value set.'

Дополнительные сведения см. в разделе [AUTOTITLE и Справочник по контекстам](/actions/security-guides/using-secrets-in-github-actions).

jobs.<job_id>.steps[*].name

Название для вашего шага для отображения на GitHub.

jobs.<job_id>.steps[*].uses

Выбирает действие, которое будет выполняться как часть шага вашего задания. Действие — это многократно используемая единица кода. Вы можете использовать действие, определенное в том же репозитории, что и рабочий процесс, в общедоступном репозитории или в опубликованном образе контейнера Docker.

Мы настоятельно рекомендуем включить версию используемого вами действия, указав ссылку на Git, SHA или тег Docker. Если вы не укажете версию, это может нарушить ваши рабочие процессы или вызвать непредвиденное поведение, когда владелец действия будет публиковать обновление.

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

Для некоторых действий требуются входные данные, заданные с помощью ключевого слова with. Просмотрите файл README действия, чтобы определить необходимые ввода.

Действия — это файлы JavaScript или контейнеры Docker. Если используемое действие является контейнером Docker, необходимо запустить задание в среде Linux. Дополнительные сведения см. в статье runs-on.

Пример. Использование действий с версиями

steps:
  # Reference a specific commit
  - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3
  # Reference the major version of a release
  - uses: actions/checkout@v5
  # Reference a specific version
  - uses: actions/checkout@v5.2.0
  # Reference a branch
  - uses: actions/checkout@main

Пример. Использование общедоступного действия

{owner}/{repo}@{ref}

Вы можете указать ветку, ссылку или SHA в публичном GitHub репозитории.

jobs:
  my_first_job:
    steps:
      - name: My first step
        # Uses the default branch of a public repository
        uses: actions/heroku@main
      - name: My second step
        # Uses a specific version tag of a public repository
        uses: actions/aws@v2.0.1

Пример. Использование общедоступного действия в подкаталоге

{owner}/{repo}/{path}@{ref}

Подкаталог в публичном GitHub репозитории в конкретном филиале, ссылке или SHA.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: actions/aws/ec2@main

Пример. Использование действия в том же репозитории, что и рабочий процесс

./path/to/dir

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

Пример структуры файла репозитория:

|-- hello-world (repository)
|   |__ .github
|       └── workflows
|           └── my-first-workflow.yml
|       └── actions
|           |__ hello-world-action
|               └── action.yml

Путь является относительным (./) к рабочему каталогу по умолчанию (github.workspace, $GITHUB_WORKSPACE). Если действие извлекает репозиторий в расположение, отличное от рабочего процесса, необходимо обновить относительный путь, используемый для локальных действий.

Пример файла рабочего процесса:

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@v5
      # 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.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: docker://alpine:3.8

Пример. Использование действия общедоступного реестра Docker

docker://{host}/{image}:{tag}

Образ Docker в общедоступном реестре. В этом примере используется реестр контейнеров Google: gcr.io.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: docker://gcr.io/cloud-builders/gradle

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

Рабочий процесс должен извлечь частный репозиторий и ссылаться на действие локально. Сгенерируйте a personal access token и добавьте токен как секрет. Дополнительные сведения см. в разделе [AUTOTITLE и Управление личными маркерами доступа](/actions/security-guides/using-secrets-in-github-actions).

Замените PERSONAL_ACCESS_TOKEN в примере именем секрета.

jobs:
  my_first_job:
    steps:
      - name: Check out repository
        uses: actions/checkout@v5
        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.

jobs.<job_id>.steps[*].run

Запускает программы командной строки, не превышающие 21 000 символов с помощью оболочки операционной системы. Если name не указано, в качестве имени шага по умолчанию используется текст, указанный в команде run.

Команды выполняются с помощью оболочки, не требующей входа, по умолчанию. Вы можете выбрать другую оболочку и настроить ее для выполнения команд. Дополнительные сведения см. в разделе jobs.<job_id>.steps[*].shell.

Каждое ключевое слово run представляет новый процесс и оболочку в среде средства выполнения. При предоставлении команд с несколькими строками каждая строка выполняется в той же оболочке. Например:

• Команда с одной строкой:

  - name: Install Dependencies
    run: npm install
  

• Команда с несколькими строками:

  - name: Clean install dependencies and build
    run: |
      npm ci
      npm run build
  

jobs.<job_id>.steps[*].working-directory

С помощью ключевого слова working-directory можно указать рабочий каталог, в котором будет выполняться команда.

- name: Clean temp directory
  run: rm -rf *
  working-directory: ./temp

Кроме того, можно указать рабочий каталог по умолчанию для всех run шагов в задании или для всех run шагов всего рабочего процесса. Дополнительные сведения см. в разделах defaults.run.working-directory и jobs.<job_id>.defaults.run.working-directory.

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

jobs.<job_id>.steps[*].shell

Параметры оболочки по умолчанию можно переопределить в операционной системе runner и по умолчанию задания с помощью ключевого shell слова. Можно использовать встроенные ключевые слова shell или определить пользовательский набор параметров оболочки. Команда оболочки, выполняемая внутри системы, исполняет временный файл, содержащий команды, указанные в ключевом слове run.

Кроме того, можно указать оболочку по умолчанию для всех run шагов в задании или для всех run шагов всего рабочего процесса. Дополнительные сведения см. в разделах defaults.run.shell и jobs.<job_id>.defaults.run.shell.

Пример. Выполнение команды с помощью Bash

steps:
  - name: Display the path
    shell: bash
    run: echo $PATH

Пример. Выполнение команды с помощью Windows cmd

steps:
  - name: Display the path
    shell: cmd
    run: echo %PATH%

Пример. Выполнение команды с помощью PowerShell Core

steps:
  - name: Display the path
    shell: pwsh
    run: echo ${env:PATH}

Пример. Использование PowerShell Desktop для выполнения команды

steps:
  - name: Display the path
    shell: powershell
    run: echo ${env:PATH}

Пример. Выполнение встроенного скрипта Python

steps:
  - name: Display the path
    shell: python
    run: |
      import os
      print(os.environ['PATH'])

Пользовательская оболочка

Вы можете задать для значения shell строку шаблона с помощью command [options] {0} [more_options]. GitHub интерпретирует первое слово строки, разделённое пробелами, как команду и вставляет имя файла временного скрипта в {0}.

Например:

steps:
  - name: Display the environment variables and their values
    shell: perl {0}
    run: |
      print %ENV

Используемая команда, в этом примере perl, должна быть установлена в средстве выполнения.

Коды выхода и настройки действий в случае ошибок

Для встроенных 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.<job_id>.steps[*].with

          `map` параметров ввода, определяемых действием. Каждый параметр ввода представляет собой пару "ключ-значение". Параметры ввода задаются как переменные среды. Переменная имеет префикс `INPUT_` и преобразуется в верхний регистр.

Входные параметры, определенные для контейнера Docker, должны использоваться args. Дополнительные сведения см. в разделе jobs.<job_id>.steps[*].with.args.

Пример jobs.<job_id>.steps[*].with

Определяет три входных параметра (first_name, middle_name и last_name), определенные действием hello_world. Эти входные переменные будут доступны для действия hello-world как переменные среды INPUT_FIRST_NAME, INPUT_MIDDLE_NAME и INPUT_LAST_NAME.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: actions/hello_world@main
        with:
          first_name: Mona
          middle_name: The
          last_name: Octocat

jobs.<job_id>.steps[*].with.args

Строка string, определяющая входные данные для контейнера Docker. GitHub передаёт args``ENTRYPOINT контейнеры контейнерам, когда контейнер запускается. array of strings не поддерживается этим параметром. Один аргумент, содержащий пробелы, должен быть окружен двойными кавычками "".

Пример jobs.<job_id>.steps[*].with.args

steps:
  - name: Explain why this job ran
    uses: octo-org/action-name@main
    with:
      entrypoint: /bin/echo
      args: The ${{ github.event_name }} event triggered this step.

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

1. Задокументируйте обязательные аргументы в README действия и опустите их из инструкции CMD.
2. Используйте значения по умолчанию, позволяющие использовать действие без указания args.
3. Если действие предоставляет флаг --help или что-то подобное, используйте его по умолчанию, чтобы действие документировало само себя.

jobs.<job_id>.steps[*].with.entrypoint

Переопределяет параметр ENTRYPOINT Docker в Dockerfile или задает его, если он еще не был указан. В отличие от инструкции Docker ENTRYPOINT, которая имеет форму оболочки и выполнения, ключевое слово entrypoint принимает только одну строку, определяющую исполняемый файл для запуска.

Пример jobs.<job_id>.steps[*].with.entrypoint

steps:
  - name: Run a custom command
    uses: octo-org/action-name@main
    with:
      entrypoint: /a/different/executable

Ключевое слово entrypoint предназначено для использования с действиями контейнера Docker, но его также можно использовать с действиями JavaScript, которые не определяют входные данные.

jobs.<job_id>.steps[*].env

Задает переменные для шагов, используемых в среде запуска. Можно также задать переменные для всего рабочего процесса или задания. Дополнительные сведения см. в разделах env и jobs.<job_id>.env.

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

Общедоступные действия могут указывать ожидаемые переменные в файле README. Если вы задаете секретное или конфиденциальное значение, например пароль или маркер, необходимо задать секреты с помощью контекста secrets . Дополнительные сведения см. в разделе Справочник по контекстам.

Пример jobs.<job_id>.steps[*].env

steps:
  - name: My first action
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      FIRST_NAME: Mona
      LAST_NAME: Octocat

jobs.<job_id>.steps[*].continue-on-error

Предотвращает сбой задания при сбое шага. Задайте значение true, чтобы задание считалось выполненным при сбое этого шага.

jobs.<job_id>.steps[*].timeout-minutes

Максимальное количество минут для выполнения шага перед завершением процесса. Максимум: 360 как GitHubдля ведущих, так и для самостоятельных бегунов.

Дробные значения не поддерживаются. timeout-minutes должно быть положительным целым числом.

jobs.<job_id>.timeout-minutes

Максимальное количество минут для запуска задания GitHub автоматически отменяет её. Значение по умолчанию: 360

Если время ожидания превышает ограничение по времени выполнения задания для средства выполнения, задание будет отменено, когда будет достигнуто ограничение времени выполнения. Для получения дополнительной информации о сроках выполнения заданий см. Выставление счетов и использование для GitHub-hosted runners и Ограничения действий для лимитов использования самостоятельных пользователей.

          Срок действия `GITHUB_TOKEN` истекает при завершении задания или в течение не более 24 часов. Для самостоятельных пользователей токен может быть ограничивающим фактором, если тайм-аут превышает 24 часа. Дополнительные сведения об этом `GITHUB_TOKEN`см. в разделе [AUTOTITLE](/actions/security-guides/automatic-token-authentication#about-the-github_token-secret).

jobs.<job_id>.strategy

Используйте jobs.<job_id>.strategy для применения стратегии матрицы к заданиям. Стратегия матрицы позволяет использовать переменные в одном определении задания для автоматического создания нескольких выполнений заданий, основанных на сочетаниях переменных. Например, можно использовать стратегию матрицы для тестирования кода в нескольких версиях языка или в нескольких операционных системах. Для получения дополнительной информации см. Выполнение вариантов заданий в рабочем процессе.

jobs.<job_id>.strategy.matrix

Используйте jobs.<job_id>.strategy.matrix для создания матрицы различных конфигураций заданий Дополнительные сведения см. в разделе Выполнение вариантов заданий в рабочем процессе.

Матрица создаст не более 256 заданий для каждого выполнения рабочего процесса. Это ограничение распространяется как GitHubна -hosting, так и на самостоятельных бегунов.

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

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

Использование матрицы с одним измерением

Следующий рабочий процесс определяет переменную version со значениями [10, 12, 14]. Рабочий процесс будет выполнять три задания, по одному для каждого значения в переменной. Каждое задание будет получать доступ к значению version через контекст matrix.version и передавать значение node-version в действие actions/setup-node.

jobs:
  example_matrix:
    strategy:
      matrix:
        version: [10, 12, 14]
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.version }}

Использование многомерной матрицы

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

Например, для следующего рабочего процесса устанавливаются две переменные:

• Две операционные системы, указанные в переменной os
• Три версии Node.js, указанные в переменной version

Рабочий процесс будет выполнять шесть заданий, по одному для каждой комбинации переменных os и version. В каждом задании параметру runs-on присваивается текущее значение os и передается текущее значение version в действие actions/setup-node.

jobs:
  example_matrix:
    strategy:
      matrix:
        os: [ubuntu-22.04, ubuntu-24.04]
        version: [10, 12, 14]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.version }}

Конфигурация переменной в матрице может иметь значение array``objects. Например, следующая матрица создает 4 задания с соответствующими контекстами.

matrix:
  os:
    - ubuntu-latest
    - macos-latest
  node:
    - version: 14
    - version: 20
      env: NODE_OPTIONS=--openssl-legacy-provider

Каждое задание в матрице будет иметь собственное сочетание os и node значения, как показано ниже.

- 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.<job_id>.strategy.matrix.include

Для каждого объекта в списке include пары ключ:значение в объекте будут добавлены к каждой из комбинаций матриц, если ни одна из пар ключ:значение не перезаписывает какие-либо исходные значения матрицы. Если объект не может быть добавлен в какие-либо комбинации матриц, будет создана новая. Обратите внимание, что исходные матричные значения не будут перезаписаны, но добавленные матричные значения могут быть перезаписаны.

Пример. Развертывание конфигураций

Например, следующий рабочий процесс будет выполнять четыре задания, по одному для каждого сочетания os и node. Если выполняется задание для значения windows-latest параметра os и значения 16 параметра node, в задание будет включена дополнительная переменная npm со значением 6.

jobs:
  example_matrix:
    strategy:
      matrix:
        os: [windows-latest, ubuntu-latest]
        node: [14, 16]
        include:
          - os: windows-latest
            node: 16
            npm: 6
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - if: ${{ matrix.npm }}
        run: npm install -g npm@${{ matrix.npm }}
      - run: npm --version

Пример. Добавление конфигураций

Например, в этой матрице будет выполняться 10 заданий, по одному для каждого сочетания os и version в матрице, а также еще одно задание для windows-latest со значением os и 17 со значением version.

jobs:
  example_matrix:
    strategy:
      matrix:
        os: [macos-latest, windows-latest, ubuntu-latest]
        version: [12, 14, 16]
        include:
          - os: windows-latest
            version: 17

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

jobs:
  includes_only:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        include:
          - site: "production"
            datacenter: "site-a"
          - site: "staging"
            datacenter: "site-b"

jobs.<job_id>.strategy.matrix.exclude

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

Все include сочетания обрабатываются после exclude. Это позволяет использовать include для добавления обратных комбинаций, которые были ранее исключены.

jobs.<job_id>.strategy.fail-fast

Можно управлять обработкой сбоев заданий с помощью jobs.<job_id>.strategy.fail-fast и jobs.<job_id>.continue-on-error.

jobs.<job_id>.strategy.fail-fast применяется ко всему тому. Если jobs.<job_id>.strategy.fail-fast задано значение true или его выражение оценивается true, GitHub отменит все выполняемые и очередные задания в матрице, если любое задание в матрице завершается ошибкой. По умолчанию свойство имеет значение true.

jobs.<job_id>.continue-on-error применяется к одному заданию. Если jobs.<job_id>.continue-on-error имеет значение true, другие задания в матрице будут продолжать выполняться, даже если задание с jobs.<job_id>.continue-on-error: true завершается сбоем.

Можно использовать jobs.<job_id>.strategy.fail-fast и jobs.<job_id>.continue-on-error совместно. Например, следующий рабочий процесс запустит четыре задания. Для каждого задания continue-on-error определяется значением matrix.experimental. При сбое любого из заданий с continue-on-error: false все выполняемые или помещенные в очередь задания будут отменены. При сбое задания с continue-on-error: true другие задания не будут затронуты.

jobs:
  test:
    runs-on: ubuntu-latest
    continue-on-error: ${{ matrix.experimental }}
    strategy:
      fail-fast: true
      matrix:
        version: [6, 7, 8]
        experimental: [false]
        include:
          - version: 9
            experimental: true

jobs.<job_id>.strategy.max-parallel

По умолчанию GitHub максимальное количество параллельных заданий в зависимости от доступности раннера.

jobs.<job_id>.continue-on-error

          `jobs.<job_id>.continue-on-error` применяется к одному заданию. Если `jobs.<job_id>.continue-on-error` имеет значение `true`, другие задания в матрице будут продолжать выполняться, даже если задание с `jobs.<job_id>.continue-on-error: true` завершается сбоем.

Предотвращает сбой выполнения рабочего процесса при сбое задания. Установите значение true, чтобы разрешить выполнение рабочего процесса в случае сбоя этого задания.

Пример. Предотвращение сбоя рабочего процесса в случае сбоя определенного задания матрицы

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

runs-on: ${{ matrix.os }}
continue-on-error: ${{ matrix.experimental }}
strategy:
  fail-fast: false
  matrix:
    node: [13, 14]
    os: [macos-latest, ubuntu-latest]
    experimental: [false]
    include:
      - node: 15
        os: ubuntu-latest
        experimental: true

jobs.<job_id>.container

Используйте jobs.<job_id>.container для создания контейнера для выполнения всех этапов задания, для которых еще не указан контейнер. При наличии этапов, которые используют действия скрипта и контейнера, действия контейнера будут выполняться как одноуровневые контейнеры в той же сети с теми же подключениями томов.

Если container не задан, все этапы будут выполняться непосредственно на узле, указанном, runs-on, если только этап не относится к действию, настроенному на выполнение в контейнере.

Пример. Выполнение задания в контейнере

name: CI
on:
  push:
    branches: [ main ]
jobs:
  container-test-job:
    runs-on: ubuntu-latest
    container:
      image: node:18
      env:
        NODE_ENV: development
      ports:
        - 80
      volumes:
        - my_docker_volume:/volume_mount
      options: --cpus 1
    steps:
      - name: Check for dockerenv file
        run: (ls /.dockerenv && echo Found dockerenv) || (echo No dockerenv)

name: CI
on:
  push:
    branches: [ main ]
jobs:
  container-test-job:
    runs-on: ubuntu-latest
    container:
      image: node:18
      env:
        NODE_ENV: development
      ports:
        - 80
      volumes:
        - my_docker_volume:/volume_mount
      options: --cpus 1
    steps:
      - name: Check for dockerenv file
        run: (ls /.dockerenv && echo Found dockerenv) || (echo No dockerenv)

При указании только образа контейнера можно опустить ключевое слово image.

jobs:
  container-test-job:
    runs-on: ubuntu-latest
    container: node:18

jobs.<job_id>.container.image

Используйте jobs.<job_id>.container.image для определения образа Docker, который будет использоваться в качестве контейнера для выполнения действия. Значением может быть имя образа Docker Hub или имя реестра.

jobs.<job_id>.container.credentials

Если реестру контейнеров образа требуется проверка подлинности для извлечения образа, можно использовать jobs.<job_id>.container.credentials, чтобы настроить map для username и password. Учетные данные являются теми же значениями, которые будут предоставлены команде docker login.

Пример: определение учетных данных для реестра контейнеров

container:
  image: ghcr.io/owner/image
  credentials:
     username: ${{ github.actor }}
     password: ${{ secrets.github_token }}

jobs.<job_id>.container.env

Используйте jobs.<job_id>.container.env для задания map переменных среды в контейнере.

jobs.<job_id>.container.ports

Используйте jobs.<job_id>.container.ports для задания array портов для использования в контейнере.

jobs.<job_id>.container.volumes

Используйте jobs.<job_id>.container.volumes для задания array томов, которые будет использовать контейнер. Тома можно использовать для совместного использования данных между службами или другими этапами в задании. Можно указать именованные тома Docker, анонимные тома Docker или подключения привязок на узле.

Чтобы указать том, укажите путь к источнику и назначению:

<source>:<destinationPath>.

<source> — это имя тома или абсолютный путь на хост-компьютере, а <destinationPath> — это абсолютный путь в контейнере.

Пример. Подключение томов в контейнере

volumes:
  - my_docker_volume:/volume_mount
  - /data/my_data
  - /source/directory:/destination/directory

jobs.<job_id>.container.options

Используйте jobs.<job_id>.container.options для настройки дополнительных параметров ресурса контейнера Docker. Список параметров см. в разделе docker create параметров.

jobs.<job_id>.services

Используется для размещения контейнеров служб для задания в рабочем процессе. Контейнеры служб полезны для создания баз данных или служб кэша, таких как Redis. Средство выполнения автоматически создает сеть Docker и управляет жизненным циклом контейнеров служб.

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

Если вы настраиваете задание для запуска непосредственно на компьютере средства выполнения, а шаг не использует действие контейнера, необходимо сопоставить все необходимые порты контейнера службы Docker с узлом Docker (компьютер средства выполнения). Доступ к контейнеру службы можно получить с помощью localhost и сопоставленного порта.

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

Пример. Использование localhost

В этом примере создаются две службы: nginx и redis. При указании порта контейнера, но не узла порт контейнера случайным образом назначается свободному порту на узле. GitHub устанавливает ${{job.services.<service_name>.ports}} назначенный хост-порт в контексте. В этом примере вы можете получить доступ к портам хоста сервиса с помощью ${{ job.services.nginx.ports['80'] }} контекстов и ${{ job.services.redis.ports['6379'] }}

services:
  nginx:
    image: nginx
    # Map port 8080 on the Docker host to port 80 on the nginx container
    ports:
      - 8080:80
  redis:
    image: redis
    # Map random free TCP port on Docker host to port 6379 on redis container
    ports:
      - 6379/tcp
steps:
  - run: |
      echo "Redis available on 127.0.0.1:${{ job.services.redis.ports['6379'] }}"
      echo "Nginx available on 127.0.0.1:${{ job.services.nginx.ports['80'] }}"

jobs.<job_id>.services.<service_id>.image

Образ Docker для использования в качестве контейнера для выполнения действия. Значением может быть имя образа Docker Hub или имя реестра.

Если jobs.<job_id>.services.<service_id>.image назначена пустая строка, служба не запустится. Это можно использовать для настройки условных служб, как показано в следующем примере.

services:
  nginx:
    image: ${{ options.nginx == true && 'nginx' || '' }}

jobs.<job_id>.services.<service_id>.credentials

Если реестру контейнеров образа требуется проверка подлинности для извлечения образа, можно использовать jobs.<job_id>.container.credentials, чтобы настроить map для username и password. Учетные данные являются теми же значениями, которые будут предоставлены команде docker login.

Пример jobs.<job_id>.services.<service_id>.credentials

services:
  myservice1:
    image: ghcr.io/owner/myservice1
    credentials:
      username: ${{ github.actor }}
      password: ${{ secrets.github_token }}
  myservice2:
    image: dockerhub_org/myservice2
    credentials:
      username: ${{ secrets.DOCKER_USER }}
      password: ${{ secrets.DOCKER_PASSWORD }}

jobs.<job_id>.services.<service_id>.env

Задает map переменных среды в контейнере службы.

jobs.<job_id>.services.<service_id>.ports

Задает array портов для предоставления в контейнере службы.

jobs.<job_id>.services.<service_id>.volumes

Задает array тома для используемого контейнера службы. Тома можно использовать для совместного использования данных между службами или другими этапами в задании. Можно указать именованные тома Docker, анонимные тома Docker или подключения привязок на узле.

Чтобы указать том, укажите путь к источнику и назначению:

          `<source>:<destinationPath>`.

          `<source>` — это имя тома или абсолютный путь на хост-компьютере, а `<destinationPath>` — это абсолютный путь в контейнере.

Пример jobs.<job_id>.services.<service_id>.volumes

volumes:
  - my_docker_volume:/volume_mount
  - /data/my_data
  - /source/directory:/destination/directory

jobs.<job_id>.services.<service_id>.options

Дополнительные параметры ресурса контейнера Docker. Список параметров см. в разделе docker create параметров.

jobs.<job_id>.uses

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

• {owner}/{repo}/.github/workflows/{filename}@{ref} для повторно используемых рабочих процессов в public, internal and private репозитории.
• ./.github/workflows/{filename} для повторно используемых рабочих процессов в одном репозитории.

В первом варианте {ref} может быть SHA, тег выпуска или имя ветви. Если тег выпуска и ветвь имеют то же имя, тег выпуска имеет приоритет над именем ветви. Использование sha фиксации является самым безопасным вариантом для стабильности и безопасности. Дополнительные сведения см. в разделе Справочник по безопасному использованию.

Если используется второй параметр синтаксиса (без {owner}/{repo} и) вызываемого рабочего процесса происходит из той же фиксации, что и @{ref}рабочий процесс вызывающего объекта. Префиксы ссылок, такие как refs/heads и refs/tags не допускаются. В этом ключевом слове нельзя использовать контексты или выражения.

Пример jobs.<job_id>.uses

jobs:
  call-workflow-1-in-local-repo:
    uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89
  call-workflow-2-in-local-repo:
    uses: ./.github/workflows/workflow-2.yml
  call-workflow-in-another-repo:
    uses: octo-org/another-repo/.github/workflows/workflow.yml@v1

Дополнительные сведения см. в разделе Повторное использование рабочих процессов.

jobs.<job_id>.with

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

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

В отличие от jobs.<job_id>.steps[*].withтого, какие входные данные передаются jobs.<job_id>.with , недоступны в виде переменных среды в вызываемом рабочем процессе. Вместо этого можно ссылаться на входные данные с помощью контекста inputs.

Пример jobs.<job_id>.with

jobs:
  call-workflow:
    uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main
    with:
      username: mona

jobs.<job_id>.with.<input_id>

Пара, состоящая из строкового идентификатора для входных данных и значения входных данных. Идентификатор должен соответствовать имени входных данных, определенных on.workflow_call.inputs.<inputs_id> в вызываемом рабочем процессе. Тип данных значения должен соответствовать типу, определенному on.workflow_call.inputs.<input_id>.type в вызываемом рабочем процессе.

Допустимые контексты выражений: github и needs.

jobs.<job_id>.secrets

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

Все секретные данные, которые вы передаете, должны соответствовать именам, определенным в вызываемом рабочем процессе.

Пример jobs.<job_id>.secrets

jobs:
  call-workflow:
    uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main
    secrets:
      access-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}

jobs.<job_id>.secrets.inherit

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

Пример jobs.<job_id>.secrets.inherit

on:
  workflow_dispatch:

jobs:
  pass-secrets-to-workflow:
    uses: ./.github/workflows/called-workflow.yml
    secrets: inherit

on:
  workflow_call:

jobs:
  pass-secret-to-action:
    runs-on: ubuntu-latest
    steps:
      - name: Use a repo or org secret from the calling workflow.
        run: echo ${{ secrets.CALLING_WORKFLOW_SECRET }}

jobs.<job_id>.secrets.<secret_id>

Пара, состоящая из строкового идентификатора для секрета и значения секрета. Идентификатор должен соответствовать имени секрета, определенного on.workflow_call.secrets.<secret_id> в вызываемом рабочем процессе.

Допустимые контексты выражений: github, needs и secrets.

Памятка по шаблонам фильтров

Специальные символы можно использовать в фильтрах путей, ветвей и тегов.

•         `*`: соответствует нулю или нескольким символам, но не соответствует символу `/`. Например, `Octo*` соответствует `Octocat`.
  

•         `**`: соответствует нулю или более символам.
  

•         `?`: соответствует нулю или одному из предыдущих символов.
  

•         `+`: соответствует одному или нескольким предыдущим символам.
  

•         `[]` Соответствует одному буквенно-цифровому символу, указанному в скобках или включенным в диапазоны. Диапазоны могут включать только `a-z`, `A-Z` и `0-9`. Например, диапазон `[0-9a-z]` соответствует любой цифре или строчной букве. Например, `[CB]at` соответствует `Cat` или `Bat`, а `[1-2]00` соответствует `100` и `200`.
  

•         `!`: в начале шаблона приводит к отмене предыдущих положительных шаблонов. Если не является первым символом, не имеет особого значения.
  

Символы *, [ и ! являются специальными символами в YAML. Если вы начинаете шаблон с *, [ или !, необходимо заключить шаблон в кавычки. Кроме того, при использовании последовательности потоков с шаблоном, содержащим [ и (или) ]шаблон должен быть заключен в кавычки.

# Valid
paths:
  - '**/README.md'

# Invalid - creates a parse error that
# prevents your workflow from running.
paths:
  - **/README.md

# Valid
branches: [ main, 'release/v[0-9].[0-9]' ]

# Invalid - creates a parse error
branches: [ main, release/v[0-9].[0-9] ]

Дополнительные сведения о синтаксисе фильтра ветвей, тегов и путей см. в разделе on.<push>.<branches|tags>,on.<pull_request>.<branches|tags> а on.<push|pull_request>.pathsтакже .

Шаблоны для сопоставления ветвей и тегов

Шаблоны для сопоставления путей к файлам

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

          _Не совпадает_<br/><br/>`README.md`<br/><br/>`docs/hello.md`      |

| '*.md'

'!README.md'

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

README.md

README.doc |