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

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

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

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

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

Оба рабочих процесса находятся в одном репозитории.
Вызываемый рабочий процесс хранится в публичном репозитории на GitHub Enterprise Server.

Нельзя напрямую использовать многоразовые рабочие процессы, определённые на GitHub.com. Вместо этого сохраняйте копию повторно используемого рабочего процесса на ваш экземпляр GitHub Enterprise Server, и вызывайте рабочий процесс по этому пути.
Вызываемый рабочий процесс хранится во внутреннем репозитории, а параметры этого репозитория позволяют получить к нему доступ. Для получения дополнительной информации см. Совместное использование действий и рабочих процессов с вашим предприятием.
Вызываемый рабочий процесс хранится в частном репозитории, а параметры этого репозитория позволяют получить доступ к нему. Для получения дополнительной информации см. Совместное использование действий и рабочих процессов с вашим предприятием.

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

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

          `private`
          , `internal`, и `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 не поддерживает перенаправления для действий или повторно используемых рабочих процессов. Это означает, что при изменении владельца, имени репозитория действия или имени действия все рабочие процессы, использующие это действие с предыдущим именем, завершаются ошибкой.

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

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

Например, 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 см. в разделе Справочник по контекстам.

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

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

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

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

Значения заполнителей в `runs-on` ключе

Следующие значения в runs-on ключе также рассматриваются как заполнители:

        `ubuntu-latest` заменено на `[ self-hosted ]`

        `windows-latest` заменено на `[ self-hosted, windows ]`

        `macos-latest"` заменено на `[ self-hosted, macOS ]`

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

Этот файл с именем 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

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": "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`
         - 
        **Необязательно**. Определяет категории, в которые отображается рабочий процесс. Имена категорий можно использовать из следующих списков:
```
- Общие имена категорий из репозитория начальных рабочих процессов.
- Языки Linguist из списка в лингвистском репозитории.
- Поддерживаемые стеки технологий из списка в репозитории начальных рабочих процессов.

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

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

В этой статье