Повторное использовать конфигурации рабочих процессов

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

В этой статье

Рабочие процессы с возможностью повторного использования

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

Доступ к повторно используемым рабочим процессам

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

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

Репозиторий вызывающего абонентаРепозитории доступных рабочих процессов
private
          `private`
          , `internal`, и `public` |

| | | internal | internal и public | | | | public | public |

          **Разрешения** "Действия" на странице "Действия" репозитория вызывающих объектов должны быть настроены для разрешения использования действий и повторно используемых рабочих процессов. См[. раздел AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-select-actions-and-reusable-workflows-to-run).

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

Примечание.

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

Ограничения повторно используемых рабочих процессов

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

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

    Например, top-level-caller-workflow.yml →____called-workflow-1.yml → called-workflow-2.yml считается 2 повторно используемыми рабочими процессами.

  • Любые переменные среды, заданные в контексте env, определенном на уровне рабочего процесса в вызывающем рабочем процессе, не распространяются на вызываемый рабочий процесс. Дополнительные сведения см. в разделе [AUTOTITLE и Хранение сведений в переменных](/actions/learn-github-actions/contexts#env-context).

  • Аналогичным образом переменные среды, заданные в контексте, определенном в env вызываемом рабочем процессе, недоступны в env контексте вызывающего рабочего процесса. Вместо этого необходимо использовать выходные данные повторно используемого рабочего процесса. Дополнительные сведения см. в разделе "Использование выходных данных из повторно используемого рабочего процесса".

  • Чтобы повторно использовать переменные в нескольких рабочих процессах, задайте их на уровне организации, репозитория или среды и сослаться на них с помощью контекста vars . Дополнительные сведения см. в разделе [AUTOTITLE и Хранение сведений в переменных](/actions/learn-github-actions/contexts#vars-context).

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

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

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

  • jobs.<job_id>.name

  • jobs.<job_id>.uses

  • jobs.<job_id>.with

  • jobs.<job_id>.with.<input_id>

  • jobs.<job_id>.secrets

  • jobs.<job_id>.secrets.<secret_id>

  • jobs.<job_id>.secrets.inherit

  • jobs.<job_id>.strategy

  • jobs.<job_id>.needs

  • jobs.<job_id>.if

  • jobs.<job_id>.concurrency

  • jobs.<job_id>.permissions

    Примечание.

    • Если jobs.<job_id>.permissions не указан в вызывающем задании, вызываемый рабочий процесс будет иметь разрешения по умолчанию для GITHUB_TOKEN. Дополнительные сведения см. в разделе Синтаксис рабочего процесса для GitHub Actions.
    • Вызываемый рабочий процесс может снизить (а не повысить) разрешения GITHUB_TOKEN, передаваемые из вызывающего рабочего процесса.
    • Если используется jobs.<job_id>.concurrency.cancel-in-progress: true, не используйте то же значение jobs.<job_id>.concurrency.group в вызываемых и вызывающих рабочих процессах, так как это приведет к отмене рабочего процесса, который уже запущен. Вызываемый рабочий процесс использует имя своего workflow вызывающего в $, поэтому использование этого контекста в качестве значения jobs.<job_id>.concurrency.group как в обеих процессах, так и в вызываемых рабочих процессах приведёт к отмене процесса вызова при запуске вызова.

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

          GitHub- Ведущие бегунов

Назначение GitHub-hosted runners всегда оценивается только с использованием контекста вызывающего. Выставление счетов GitHubдля ведущих бегунов всегда связано с звонящим. Рабочий процесс вызывающего не может использовать GitHub-hosted runners из вызываемого репозитория. Дополнительные сведения см. в разделе Средства выполнения тестов, размещенные в GitHub.

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

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

  • в репозитории вызывающего;
  • В организации или предприятии репозитории звонящего, при условии, что раннер был доступен репозиторию звонящего

Доступ и разрешения для вложенных рабочих процессов

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

Разрешения GITHUB_TOKEN во вложенных рабочих процессах могут быть такими же или более ограничивающими. Например, в цепочке рабочих процессов A > B > C, если рабочий процесс A имеет разрешение package: read, B и C не могут иметь разрешения package: write. Дополнительные сведения см. в разделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах.

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

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

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

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

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

Контекст github

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

Шаблоны рабочих процессов

Справочная информация, используемая при создании шаблонов рабочих процессов для организации.

Доступность шаблона рабочего процесса

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

  • Шаблоны рабочих процессов в общедоступном .github репозитории доступны для всех типов репозитория.
  • Шаблоны рабочих процессов в внутреннем репозитории доступны только для внутренних .github и частных репозиториев.
  • Шаблоны рабочих процессов в частном репозитории доступны только для частных .github репозиториев.

Поскольку шаблоны публичных рабочих процессов требуют публичного .github репозитория, они недоступны для Enterprise Managed Users.

Предоставление доступа для частных и внутренних репозиториев

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

Заполнитель $default-branch

Если вам нужно ссылаться на ветвь по умолчанию репозитория, можно использовать $default-branch заполнитель в шаблоне рабочего процесса. При создании рабочего процесса этот заполнитель автоматически заменяется именем ветви по умолчанию репозитория.

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

Этот файл с именем octo-organization-ci.yml демонстрирует базовый рабочий процесс.

YAML
name: Octo Organization CI
on:
  push:
    branches: [ $default-branch ]
  pull_request:
    branches: [ $default-branch ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - name: Run a one-line script
        run: echo Hello from Octo Organization

Требования к файлу метаданных

Файл метаданных должен иметь то же имя, что и файл рабочего процесса, однако вместо расширения .yml должно быть добавлено .properties.json. Например, файл с именем octo-organization-ci.properties.json содержит метаданные для файла рабочего процесса с именем octo-organization-ci.yml.

JSON
{
    "name": "Octo Organization Workflow",
    "description": "Octo Organization CI workflow template.",
    "iconName": "example-icon",
    "categories": [
        "Go"
    ],
    "filePatterns": [
        "package.json$",
        "^Dockerfile",
        ".*\\.md$"
    ]
}

  •         `name`
         - 
        **Необходимые**. Название рабочего процесса. Отображается в списке доступных рабочих процессов.

  •         `description`
         - 
        **Необходимые**. Описание рабочего процесса. Отображается в списке доступных рабочих процессов.

  •         `iconName`
         - 
        **Необязательно**. Указывает значок рабочего процесса, отображаемого в списке рабочих процессов. 
        `iconName` Может быть одним из следующих типов:
    • ФАЙЛ SVG, хранящийся в каталоге workflow-templates . Чтобы ссылаться на файл, значение должно быть именем файла без расширения файла. Например, на файл SVG с именем example-icon.svg будет даваться ссылка example-icon.
    • Значок из набора данных GitHubнабора Octicons. Чтобы ссылаться на октикон, значение должно быть octicon <icon name>. Например: octicon smiley.
  •         `categories`
         - 
        **Необязательно**. Определяет категории, в которые отображается рабочий процесс. Имена категорий можно использовать из следующих списков:

  •         `filePatterns`
         - 
        **Необязательно**. Позволяет использовать рабочий процесс, если репозиторий пользователя содержит файл в корневом каталоге, соответствующий определенному регулярному выражению.

Привязки и псевдонимы YAML

Привязки и псевдонимы YAML можно использовать для уменьшения повторения в рабочих процессах. Привязка (помеченная с &помощью) идентифицирует фрагмент содержимого, который требуется повторно использовать, а псевдоним (помеченный с *) повторяет это содержимое в другом расположении.

Подробные сведения об привязках и псевдонимах см . в разделе "Привязки узлов" и "Псевдонимы" в спецификации YAML.

Ниже приведен пример использования привязок YAML и псевдонимов с переменными среды:

jobs:
  job1:
    env: &env_vars # Define the anchor on first use
      NODE_ENV: production
      DATABASE_URL: ${{ secrets.DATABASE_URL }}
    steps:
      - run: echo "Using production settings"

  job2:
    env: *env_vars # Reuse the environment variables
    steps:
      - run: echo "Same environment variables here"

Это эквивалентно написанию следующего YAML без привязок и псевдонимов:

jobs:
  job1:
    env:
      NODE_ENV: production
      DATABASE_URL: ${{ secrets.DATABASE_URL }}
    steps:
      - run: echo "Using production settings"

  job2:
    env:
      NODE_ENV: production
      DATABASE_URL: ${{ secrets.DATABASE_URL }}
    steps:
      - run: echo "Same environment variables here"

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

jobs:
  test: &base_job # Define the anchor on first use
    runs-on: ubuntu-latest
    timeout-minutes: 30
    env:
      NODE_VERSION: '18'
    steps:
      - uses: actions/checkout@v5
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
      - run: npm test

  alt-test: *base_job # Reuse the entire job configuration