Синтаксис рабочего процесса для 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 принимают стандартные маски, использующие такие символы, как *, **, +, ?, ! и другие, чтобы соответствовать нескольким именам ветвей. Если имя содержит любой из этих символов и требуется буквальное совпадение, необходимо экранировать каждый из этих специальных символов с помощью \. Дополнительные сведения о стандартных шаблонах см. в разделе Синтаксис рабочего процесса для GitHub Actions.

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

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

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

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

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

В случае соответствия шаблона branches-ignore рабочий процесс не будет выполняться. Шаблоны, определенные в branches, оцениваются по имени ссылки 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 одновременно.

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

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

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

Шаблоны, определенные в 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, например beta/3-alpha (refs/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 одновременно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этот пример запускается каждый раз, когда событие 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 непосредственно друг с другом.
• Отправки в новые ветви. Различие с двумя точками в сравнении с родителем предка самой глубокой отправленной фиксации.

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

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

on.schedule

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

В этом примере рабочий процесс запускается каждый день в 5:30 и 17:30 (в формате UTC):

on:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron:  '30 5,17 * * *'

Один рабочий процесс может запускаться несколькими событиями schedule. Доступ к запланированному событию, при возникновении которого был запущен рабочий процесс, можно получить с помощью контекста github.event.schedule. В этом примере рабочий процесс запускается с ежедневно с понедельника по четверг в 5:30 (в формате UTC), причем по понедельникам и средам шаг Not on Monday or Wednesday пропускается.

on:
  schedule:
    - cron: '30 5 * * 1,3'
    - cron: '30 5 * * 2,4'

jobs:
  test_schedule:
    runs-on: ubuntu-latest
    steps:
      - name: Not on Monday or Wednesday
        if: github.event.schedule != '30 5 * * 1,3'
        run: echo "This step will be skipped on Monday and Wednesday"
      - name: Every time
        run: echo "This step will always run"

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

on.workflow_call

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

on.workflow_call.inputs

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

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

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

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

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

Пример on.workflow_call.inputs

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

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

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

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

on.workflow_call.inputs.<input_id>.type

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

on.workflow_call.outputs

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

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

Пример on.workflow_call.outputs

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

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

on.workflow_call.secrets

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

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

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

Пример on.workflow_call.secrets

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

jobs:

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

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

on.workflow_call.secrets.<secret_id>

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

on.workflow_call.secrets.<secret_id>.required

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

on.workflow_run.<branches|branches-ignore>

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

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

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

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

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

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

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

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

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

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

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

on.workflow_dispatch

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

on.workflow_dispatch.inputs

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

Пример 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или string.

permissions

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

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

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

concurrency

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

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

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

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

concurrency: staging_environment

concurrency: ci-${{ github.ref }}

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

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

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

Если вы создаете имя группы со свойством, определенным только для определенных событий, можно использовать резервное значение. Например, 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

jobs

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

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

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

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

jobs.<job_id>

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

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

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

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

jobs.<job_id>.name

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

jobs.<job_id>.permissions

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

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

Доступные области и значения доступа:

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

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

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

permissions: read-all|write-all

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

permissions: {}
``` С помощью ключа `permissions` можно добавлять и удалять разрешения на чтение для разветвленных репозиториев, но обычно предоставить доступ на запись нельзя. Исключением из этого поведения является то, что пользователь администратора выбрал **Отправлять маркеры записи в рабочие процессы из запросов на вытягивание** в параметрах GitHub Actions. Дополнительные сведения см. в разделе [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks).

### Пример. Настройка разрешений для определенного задания

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

```yaml
jobs:
  stale:
    runs-on: ubuntu-latest

    permissions:
      issues: write
      pull-requests: write

    steps:
      - uses: actions/stale@v5

jobs.<job_id>.needs

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

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

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 автоматически обрабатывает условную директиву if как выражение. Дополнительные сведения см. в разделе Выражения.

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

В этом примере используется 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@v3
      - uses: actions/setup-node@v3
        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@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm install -g bats

jobs.<job_id>.runs-on

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

— конечным компьютером может быть либо средство выполнения, размещенное в GitHub, Более крупное средство выполнения, либо локальное средство выполнения.

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

• Вы можете указать следующее runs-on :

  • одна строка
  • одна переменная, содержащая строку
  • массив строк, переменных, содержащих строки, или сочетание обоих элементов

• Если указать массив строк или переменных, рабочий процесс будет выполняться в любом средстве выполнения, которое соответствует всем указанным runs-on значениям. Например, здесь задание будет выполняться только в локальном средстве выполнения, которое имеет метки 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, "${{ github.event.inputs.chosen-os }}"]
    steps:
    - run: echo Hello world!

• Если необходимо запустить рабочий процесс на нескольких компьютерах, используйте jobs.<job_id>.strategy.

Выбор средства выполнения тестов, размещенного на GitHub

При использовании средства выполнения тестов, размещенного на GitHub, каждое задание выполняется в новом экземпляре образа средства выполнения тестов, заданной параметром runs-on.

Доступны следующие типы средств выполнения тестов, размещенных на GitHub:

Пример: указание операционной системы

runs-on: ubuntu-latest

Дополнительные сведения см. в разделе О средствах выполнения, размещенных в GitHub.

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

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

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

Несмотря на то что метка self-hosted не является обязательной, настоятельно рекомендуется указать ее при использовании локальных средств выполнения тестов, чтобы убедиться, что задание не указывает случайно текущие или будущие данные средства выполнения тестов, размещенные в GitHub.

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

runs-on: [self-hosted, linux]

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

Выбор средств выполнения в группе

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

В группах средств выполнения могут быть только Более крупное средство выполненияs или локальные средства выполнения тестов в качестве участников.

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

В этом примере средства выполнения 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@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

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

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

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

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

jobs.<job_id>.environment

Используется jobs.<job_id>.environment для определения среды, на которую ссылается задание. Чтобы задание, ссылающееся на среду, было отправлено в средство выполнения, должны соблюдаться все правила защиты среды. Дополнительные сведения см. в разделе Использование сред для развертывания.

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

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

environment: staging_environment

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

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

Значение url может быть выражением. Допустимые контексты выражений: github, inputs, vars, needs, strategymatrix, job, runnerи env. Дополнительные сведения о выражениях см. в разделе Выражения.

Пример. Использование выходных данных в качестве 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. Все задания или рабочие процессы в группе параллелизма, находившиеся в состоянии ожидания, будут отменены. Чтобы также отменить задание или рабочий процесс, которые сейчас выполняются в той же группе параллелизма, укажите cancel-in-progress: true.

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

concurrency: staging_environment

concurrency: ci-${{ github.ref }}

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

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

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

Если вы создаете имя группы со свойством, определенным только для определенных событий, можно использовать резервное значение. Например, 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

jobs.<job_id>.outputs

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

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

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

Чтобы применять выходные данные задания в зависимом задании, можно использовать контекст 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.<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 для всего рабочего процесса. Дополнительные сведения см. на веб-сайте jobs.defaults.run. В этом ключевом слове нельзя использовать контексты или выражения.

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

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

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

jobs.<job_id>.steps

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

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

Пример 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 автоматически обрабатывает условную директиву if как выражение. Дополнительные сведения см. в разделе Выражения.

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

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

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

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

my backup step выполняется только при сбое предыдущего шага задания. Дополнительные сведения см. в разделе Выражения.

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

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

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

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

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

Дополнительные сведения см. в разделах Контексты и Зашифрованные секреты.

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@v3
  # Reference a specific version
  - uses: actions/checkout@v3.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

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

jobs:
  my_first_job:
    steps:
      - name: Check out repository
        uses: actions/checkout@v3
      - name: Use local my-action
        uses: ./.github/actions/my-action

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

docker://{image}:{tag}

Образ Docker, опубликованный в Docker Hub.

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

Пример. Использование GitHub Packages Container registry

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

Общедоступный образ Docker в GitHub Packages Container registry.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: docker://ghcr.io/OWNER/IMAGE_NAME

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

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

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

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

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

Рабочий процесс должен извлечь частный репозиторий и ссылаться на действие локально. Создайте personal access token и добавьте маркер в качестве зашифрованного секрета. Дополнительные сведения см. в разделах Управление личными маркерами доступа и Зашифрованные секреты.

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

jobs:
  my_first_job:
    steps:
      - name: Check out repository
        uses: actions/checkout@v3
        with:
          repository: octocat/my-private-repo
          ref: v1.0
          token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
          path: ./.github/actions/my-private-repo
      - name: Run my action
        uses: ./.github/actions/my-private-repo/my-action

Кроме того, используйте GitHub App вместо personal access token, чтобы рабочий процесс продолжал выполняться, даже если владелец personal access token уйдет. Дополнительные сведения см. в разделе Выполнение запросов API с проверкой подлинности с помощью Приложение GitHub в рабочем процессе GitHub Actions.

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

Используется для запуска программы командной строки с помощью оболочки операционной системы. Если 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
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

Сведения о программном обеспечении, включенном в средства выполнения тестов, размещенные в GitHub, см. в разделе О средствах выполнения, размещенных в GitHub.

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

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

• bash/sh:

  • Поведение с завершением работы при первой ошибке с использованием set -eo pipefail: этот параметр задается, если shell: bash указано в явном виде. Оно не применяется по умолчанию.
  • Вы можете получить полный контроль над параметрами оболочки, указав строку шаблона для параметров оболочки. Например, 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 использует наиболее конкретную переменную. Например, переменная среды, определенная в шаге, будет переопределять переменные среды задания и рабочего процесса с тем же именем, пока выполняется шаг. Переменная среды, определенная для задания, переопределяет переменную рабочего процесса с тем же именем, в то время как задание выполняется.

Открытые действия могут указывать ожидаемые переменные в файле СВЕДЕНИЙ. Если вы задаете секрет или конфиденциальное значение, например пароль или маркер, необходимо задать секреты с помощью контекста 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

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

jobs.<job_id>.timeout-minutes

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

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

jobs.<job_id>.strategy

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

jobs.<job_id>.strategy.matrix

Используйте jobs.<job_id>.strategy.matrix для создания матрицы различных конфигураций заданий В матрице определите одну или несколько переменных, за которыми следует массив значений. Например, в указанной ниже матрице есть переменная под именем version со значением [10, 12, 14] и переменная под именем os со значением [ubuntu-latest, windows-latest]:

jobs:
  example_matrix:
    strategy:
      matrix:
        version: [10, 12, 14]
        os: [ubuntu-latest, windows-latest]

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

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

• {version: 10, os: ubuntu-latest}
• {version: 10, os: windows-latest}
• {version: 12, os: ubuntu-latest}
• {version: 12, os: windows-latest}
• {version: 14, os: ubuntu-latest}
• {version: 14, os: windows-latest}

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

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

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

Можно указать одну переменную для создания одномерной матрицы.

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

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

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

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

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

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

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

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

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

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

Например, следующий рабочий процесс активирует событие repository_dispatch и использует сведения из его полезных данных для построения матрицы. При создании события диспетчеризации репозитория с полезными данными, как показано ниже, переменная version матрицы будет иметь значение [12, 14, 16]. Дополнительные сведения о триггере см. в repository_dispatch разделе События, инициирующие рабочие процессы.

{
  "event_type": "test",
  "client_payload": {
    "versions": [12, 14, 16]
  }
}

on:
  repository_dispatch:
    types:
      - test
 
jobs:
  example_matrix:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        version: ${{ github.event.client_payload.versions }}
    steps:
      - uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.version }}

jobs.<job_id>.strategy.matrix.include

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

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

Например, эта матрица:

strategy:
  matrix:
    fruit: [apple, pear]
    animal: [cat, dog]
    include:
      - color: green
      - color: pink
        animal: cat
      - fruit: apple
        shape: circle
      - fruit: banana
      - fruit: banana
        animal: cat

приведет к шести заданиям со следующими комбинациями матриц:

• {fruit: apple, animal: cat, color: pink, shape: circle}
• {fruit: apple, animal: dog, color: green, shape: circle}
• {fruit: pear, animal: cat, color: pink}
• {fruit: pear, animal: dog, color: green}
• {fruit: banana}
• {fruit: banana, animal: cat}

следуя этой логике:

• {color: green} добавляется ко всем исходным комбинациям матриц, так как его можно добавить без перезаписи любой части исходных комбинаций.
• {color: pink, animal: cat} добавляет color:pink только к исходным комбинациям матриц, которые включают animal: cat. Это перезаписывает color: green, добавленный предыдущей записью include.
• {fruit: apple, shape: circle} добавляет shape: circle только к исходным комбинациям матриц, которые включают fruit: apple.
• {fruit: banana} невозможно добавить ни в какую исходную комбинацию матриц без перезаписи значения, поэтому он добавляется в качестве дополнительной комбинации матриц.
• {fruit: banana, animal: cat} невозможно добавить ни в какую исходную комбинацию матриц без перезаписи значения, поэтому он добавляется в качестве дополнительной комбинации матриц. Он не добавляется к комбинации матриц {fruit: banana}, так как эта комбинация не была одной из исходных комбинаций матриц.

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

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

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

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

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

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

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

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

jobs.<job_id>.strategy.matrix.exclude

Чтобы удалить конкретные конфигурации, определенные в матрице, используйте jobs.<job_id>.strategy.matrix.exclude. Исключенная конфигурация должна иметь хотя бы частичное совпадение, чтобы ее можно было исключить. Например, следующий рабочий процесс будет выполнять девять заданий: одно задание для каждой из 12 конфигураций, минус одно исключенное задание, которое совпадает с {os: macos-latest, version: 12, environment: production}, и два исключенных задания, которые совпадают с {os: windows-latest, version: 16}.

strategy:
  matrix:
    os: [macos-latest, windows-latest]
    version: [12, 14, 16]
    environment: [staging, production]
    exclude:
      - os: macos-latest
        version: 12
        environment: production
      - os: windows-latest
        version: 16
runs-on: ${{ matrix.os }}

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, 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 максимизирует количество параллельно выполняемых заданий в зависимости от доступности средства выполнения. Для настройки максимального числа заданий, которые могут выполняться одновременно при применении стратегии задания matrix, используйте jobs.<job_id>.strategy.max-parallel.

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

jobs:
  example_matrix:
    strategy:
      max-parallel: 2
      matrix:
        version: [10, 12, 14]
        os: [ubuntu-latest, windows-latest]

jobs.<job_id>.continue-on-error

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

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

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

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

jobs.<job_id>.container

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

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

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

name: CI
on:
  push:
    branches: [ main ]
jobs:
  container-test-job:
    runs-on: ubuntu-latest
    container:
      image: node:14.16
      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:14.16
      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:14.16

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 и сопоставленного порта.

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

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

В этом примере создаются две службы: nginx и redis. При указании порта узла Docker (но не порта контейнера) порт контейнера случайным образом назначается свободному порту. GitHub задает назначенный порт контейнера в контексте ${{job.services.<service_name>.ports}}. В этом примере можно получить доступ к портам контейнера службы с помощью контекстов ${{ job.services.nginx.ports['8080'] }} и ${{ 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 TCP port 6379 on Docker host to a random free port on the Redis container
    ports:
      - 6379/tcp

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

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

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 и private репозитории.
• ./.github/workflows/{filename} для повторно используемых рабочих процессов в том же репозитории.

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

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

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

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

jobs.<job_id>.with

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

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

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

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

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

jobs.<job_id>.with.<input_id>

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

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

jobs.<job_id>.secrets

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

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

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

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

jobs.<job_id>.secrets.inherit

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

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

on:
  workflow_dispatch:

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

on:
  workflow_call:

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

jobs.<job_id>.secrets.<secret_id>

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

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

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

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

• *: соответствует нулю или нескольким символам, но не соответствует символу /. Например, Octo* соответствует Octocat.
• **: соответствует нулю или более символам.
• ?: соответствует нулю или одному из предыдущих символов.
• +: соответствует одному или нескольким предыдущим символам.
• []: соответствует одному символу, указанному в квадратных скобках или включенному в диапазоны. Диапазоны могут включать только a-z, A-Z и 0-9. Например, диапазон [0-9a-z] соответствует любой цифре или строчной букве. Например, [CB]at соответствует Cat или Bat, а [1-2]00 соответствует 100 и 200.
• !: в начале шаблона приводит к отмене предыдущих положительных шаблонов. Если не является первым символом, не имеет особого значения.

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

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

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

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

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

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

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

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

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