Skip to main content

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

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

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

Повторно используемые рабочие процессы — это файлы в формате YAML, очень похожие на любой другой файл рабочего процесса. Как и в случае с другими файлами рабочих процессов, повторно используемые рабочие процессы можно найти в каталоге .github/workflows репозитория. Подкаталоги каталога workflows не поддерживаются.

Чтобы рабочий процесс можно было использовать повторно, значения для on должны включать workflow_call:

on:
  workflow_call:

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

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

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

    on:
      workflow_call:
        inputs:
          config-path:
            required: true
            type: string
        secrets:
          personal_access_token:
            required: true
    

Дополнительные сведения о синтаксисе для определения входных данных и секретов см. в разделах on.workflow_call.inputs и on.workflow_call.secrets.

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

    Примечание.

    Если секреты наследуются с помощью secrets: inherit вызывающего рабочего процесса, вы можете ссылаться на них, даже если они не определены явным образом в on ключе. Дополнительные сведения см. в разделе Синтаксис рабочего процесса для GitHub Actions.

    jobs:
      reusable_workflow_job:
        runs-on: ubuntu-latest
        steps:
        - uses: actions/labeler@v6
          with:
            repo-token: ${{ secrets.personal_access_token }}
            configuration-path: ${{ inputs.config-path }}
    

    В приведенном выше примере — это секрет, personal_access_token определенный на уровне репозитория или организации.

    Предупреждение

    Секреты среды нельзя передать из рабочего процесса вызывающего объекта, так как on.workflow_call ключевое environment слово не поддерживается. Если включить environment повторно используемый рабочий процесс на уровне задания, будет использоваться секрет среды, а не секрет, переданный из вызывающего рабочего процесса. Дополнительные сведения см. в разделе [AUTOTITLE и Управление средами для развертывания](/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_call).

  2. Передайте входные или секретные данные из вызывающего рабочего процесса.

    Чтобы передать именованные входные данные в вызываемый рабочий процесс, используйте в задании ключевое слово with. Используйте ключевое слово secrets для передачи именованных секретов. Тип данных входного значения должен соответствовать типу, указанному в вызываемом рабочем процессе (логическое значение, число или строка).

    jobs:
      call-workflow-passing-data:
        uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
        with:
          config-path: .github/labeler.yml
        secrets:
          personal_access_token: ${{ secrets.token }}
    

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

    jobs:
      call-workflow-passing-data:
        uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
        with:
          config-path: .github/labeler.yml
        secrets: inherit
    

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

Этот повторно используемый файл рабочего процесса с именем workflow-B.yml (мы обратимся к нему позже в примере вызывающего рабочего процесса) принимает входную строку и секрет от вызывающего рабочего процесса и использует их в действии.

YAML
name: Reusable workflow example

on:
  workflow_call:
    inputs:
      config-path:
        required: true
        type: string
    secrets:
      token:
        required: true

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/labeler@v6
      with:
        repo-token: ${{ secrets.token }}
        configuration-path: ${{ inputs.config-path }}

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

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

jobs.<job_id>.uses

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

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

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

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

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

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

Пример вызывающего рабочего процесса

Этот файл рабочего процесса вызывает два файла рабочего процесса. Второму из них, workflow-B.yml (показанному в примере повторноно используемого рабочего процесса), передаются входные данные (config-path) и секрет (token).

YAML
name: Call a reusable workflow

on:
  pull_request:
    branches:
      - main

jobs:
  call-workflow:
    uses: octo-org/example-repo/.github/workflows/workflow-A.yml@v1

  call-workflow-passing-data:
    permissions:
      contents: read
      pull-requests: write
    uses: octo-org/example-repo/.github/workflows/workflow-B.yml@main
    with:
      config-path: .github/labeler.yml
    secrets:
      token: ${{ secrets.GITHUB_TOKEN }}

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

Чтобы передать именованные входные данные в вызываемый рабочий процесс, используйте в задании ключевое слово with. Используйте ключевое слово secrets для передачи именованных секретов. Тип данных входного значения должен соответствовать типу, указанному в вызываемом рабочем процессе (логическое значение, число или строка).

jobs:
  call-workflow-passing-data:
    uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
    with:
      config-path: .github/labeler.yml
    secrets:
      personal_access_token: ${{ secrets.token }}

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

jobs:
  call-workflow-passing-data:
    uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
    with:
      config-path: .github/labeler.yml
    secrets: inherit

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

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

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

В этом примере задания ниже вызывается повторно используемый рабочий процесс и ссылается на контекст матрицы, определяя переменную target со значениями [dev, stage, prod]. Он будет выполнять три задания, по одному для каждого значения в переменной.

YAML
jobs:
  ReusableMatrixJobForDeployment:
    strategy:
      matrix:
        target: [dev, stage, prod]
    uses: octocat/octo-repo/.github/workflows/deployment.yml@main
    with:
      target: ${{ matrix.target }}

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

Вы можете подключить максимум десяти уровней рабочих процессов — то есть верхнего уровня для звонка и до девяти уровней повторно используемых рабочих процессов. Например: caller-workflow.ymlcalled-workflow-1.yml__→ called-workflow-2.ymlcalled-workflow-3.yml → ... → called-workflow-9.yml.

Циклы в дереве рабочих процессов запрещены.

Примечание.

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

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

YAML
name: Reusable workflow

on:
  workflow_call:

jobs:
  call-another-reusable:
    uses: octo-org/example-repo/.github/workflows/another-reusable.yml@v1

Передача секретов во вложенные рабочие процессы

Вы можете использовать jobs.<job_id>.secrets в вызывающем рабочем процессе для передачи именованных секретов в непосредственно вызываемый рабочий процесс. Кроме того, вы можете использовать jobs.<job_id>.secrets.inherit для передачи всех секретов вызывающего рабочего процесса в непосредственно вызываемый рабочий процесс. Дополнительные сведения см. в разделе [AUTOTITLE выше и справочной статье Повторное использование рабочих процессов](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsecretsinherit). Секреты передаются только в непосредственно вызываемый рабочий процесс, поэтому в цепочке рабочих процессов A > B > C рабочий процесс C будет получать секреты от A, только если они переданы из A в B, а затем из B в C.

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

jobs:
  workflowA-calls-workflowB:
    uses: octo-org/example-repo/.github/workflows/B.yml@main
    secrets: inherit # pass all secrets
jobs:
  workflowB-calls-workflowC:
    uses: different-org/example-repo/.github/workflows/C.yml@main
    secrets:
      repo-token: ${{ secrets.personal_access_token }} # pass just this secret

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

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

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

В следующем повторно используемом рабочем процессе есть одно задание, содержащее два шага. В каждом из этих шагов мы задаем одно слово в качестве выходных данных: "hello" и "world". В разделе outputs задания мы сопоставляем эти выходные данные шага с выходными данными задания, называемыми: output1 и output2. Затем в разделе on.workflow_call.outputs мы определяем два набора выходных данных для самого рабочего процесса, один с именем firstword, который мы сопоставляем с output1, и один с именем secondword, который сопоставляем с output2.

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

Дополнительные сведения см. в разделе [AUTOTITLE и Передача сведений между заданиями](/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_calloutputs).

YAML
name: Reusable workflow

on:
  workflow_call:
    # Map the workflow outputs to job outputs
    outputs:
      firstword:
        description: "The first output string"
        value: ${{ jobs.example_job.outputs.output1 }}
      secondword:
        description: "The second output string"
        value: ${{ jobs.example_job.outputs.output2 }}

jobs:
  example_job:
    name: Generate output
    runs-on: ubuntu-latest
    # Map the job outputs to step outputs
    outputs:
      output1: ${{ steps.step1.outputs.firstword }}
      output2: ${{ steps.step2.outputs.secondword }}
    steps:
      - id: step1
        run: echo "firstword=hello" >> $GITHUB_OUTPUT
      - id: step2
        run: echo "secondword=world" >> $GITHUB_OUTPUT

Теперь мы можем использовать выходные данные в вызывающем рабочем процессе точно так же, как вы использовали бы выходные данные задания в том же рабочем процессе. Мы ссылаемся на выходные данные, используя имена, определенные на уровне рабочего процесса в повторно используемом рабочем процессе: firstword и secondword. В этом рабочем процессе job1 вызывает повторно используемый рабочий процесс, а job2 печатает выходные данные многократно используемого рабочего процесса ("hello world") в стандартный поток вывода в журнале рабочего процесса.

YAML
name: Call a reusable workflow and use its outputs

on:
  workflow_dispatch:

jobs:
  job1:
    uses: octo-org/example-repo/.github/workflows/called-workflow.yml@v1

  job2:
    runs-on: ubuntu-latest
    needs: job1
    steps:
      - run: echo ${{ needs.job1.outputs.firstword }} ${{ needs.job1.outputs.secondword }}

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

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

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

Следующие шаги

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