{"meta":{"title":"Повторное использование рабочих процессов","intro":"Узнайте, как избежать дублирования при создании рабочего процесса путем повторного использования существующих рабочих процессов.","product":"GitHub Actions","breadcrumbs":[{"href":"/ru/actions","title":"GitHub Actions"},{"href":"/ru/actions/how-tos","title":"Инструкции"},{"href":"/ru/actions/how-tos/reuse-automations","title":"Повторное использование автоматизации"},{"href":"/ru/actions/how-tos/reuse-automations/reuse-workflows","title":"Повторное использование рабочих процессов"}],"documentType":"article"},"body":"# Повторное использование рабочих процессов\n\nУзнайте, как избежать дублирования при создании рабочего процесса путем повторного использования существующих рабочих процессов.\n\n## Создание повторно используемых рабочих процессов\n\nПовторно используемые рабочие процессы — это файлы в формате YAML, очень похожие на любой другой файл рабочего процесса. Как и в случае с другими файлами рабочих процессов, повторно используемые рабочие процессы можно найти в каталоге `.github/workflows` репозитория. Подкаталоги каталога `workflows` не поддерживаются.\n\nЧтобы рабочий процесс можно было использовать повторно, значения для `on` должны включать `workflow_call`:\n\n```yaml\non:\n  workflow_call:\n```\n\n## Использование входных данных и секретов в повторно используемом рабочем процессе\n\nВы можете определить входные данные и секреты, которые можно передать из вызывающего рабочего процесса, а затем использовать в вызываемом рабочем процессе. Существует три этапа использования входных данных или секрета в повторно используемом рабочем процессе.\n\n1. В повторно используемом рабочем процессе используйте ключевые слова `inputs` и `secrets` для определения входных данных или секретов, которые будут передаваться из вызывающего рабочего процесса.\n\n   ```yaml\n   on:\n     workflow_call:\n       inputs:\n         config-path:\n           required: true\n           type: string\n       secrets:\n         personal_access_token:\n           required: true\n   ```\n\n   Дополнительные сведения о синтаксисе для определения входных данных и секретов см. в разделе [`on.workflow_call.inputs`](/ru/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_callinputs) и [`on.workflow_call.secrets`](/ru/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_callsecrets).\n\n2. В повторно используемом рабочем процессе укажите входные данные или секрет, определенный в ключе `on` на предыдущем шаге.\n\n   > \\[!NOTE]\n   > Если секреты наследуются с помощью `secrets: inherit` вызывающего рабочего процесса, вы можете ссылаться на них, даже если они не определены явным образом в `on` ключе. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsecretsinherit).\n\n   ```yaml\n   jobs:\n     reusable_workflow_job:\n       runs-on: ubuntu-latest\n       steps:\n       - uses: actions/labeler@v6\n         with:\n           repo-token: ${{ secrets.personal_access_token }}\n           configuration-path: ${{ inputs.config-path }}\n   ```\n\n   В приведенном выше примере — это секрет, `personal_access_token` определенный на уровне репозитория или организации.\n\n   > \\[!WARNING]\n   > Секреты среды нельзя передать из рабочего процесса вызывающего объекта, так как `on.workflow_call` ключевое `environment` слово не поддерживается. Если включить `environment` повторно используемый рабочий процесс на уровне задания, будет использоваться секрет среды, а не секрет, переданный из вызывающего рабочего процесса. Дополнительные сведения см. в разделе \\[AUTOTITLE и [Управление средами для развертывания](/ru/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments)]\\(/actions/reference/workflows-and-actions/workflow-syntax#onworkflow\\_call).\n\n3. Передайте входные или секретные данные из вызывающего рабочего процесса.\n\n   Чтобы передать именованные входные данные в вызываемый рабочий процесс, используйте в задании ключевое слово `with`. Используйте ключевое слово `secrets` для передачи именованных секретов. Тип данных входного значения должен соответствовать типу, указанному в вызываемом рабочем процессе (логическое значение, число или строка).\n\n   ```yaml\n   jobs:\n     call-workflow-passing-data:\n       uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main\n       with:\n         config-path: .github/labeler.yml\n       secrets:\n         personal_access_token: ${{ secrets.token }}\n   ```\n\n   Рабочие процессы, которые вызывают повторно используемые рабочие процессы в одной организации или организации, могут использовать `inherit` ключевое слово для неявного передачи секретов.\n\n   ```yaml\n   jobs:\n     call-workflow-passing-data:\n       uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main\n       with:\n         config-path: .github/labeler.yml\n       secrets: inherit\n   ```\n\n### Пример повторно используемого рабочего процесса\n\nЭтот повторно используемый файл рабочего процесса с именем `workflow-B.yml` (мы обратимся к нему позже в [примере вызывающего рабочего процесса](#example-caller-workflow)) принимает входную строку и секрет от вызывающего рабочего процесса и использует их в действии.\n\n```yaml copy\nname: Reusable workflow example\n\non:\n  workflow_call:\n    inputs:\n      config-path:\n        required: true\n        type: string\n    secrets:\n      token:\n        required: true\n\njobs:\n  triage:\n    runs-on: ubuntu-latest\n    steps:\n    - uses: actions/labeler@v6\n      with:\n        repo-token: ${{ secrets.token }}\n        configuration-path: ${{ inputs.config-path }}\n```\n\n## Вызов повторно используемого рабочего процесса\n\nПовторно используемый рабочий процесс вызывается с помощью ключевого слова `uses`. В отличие от случаев, когда в рабочем процессе используются действия, повторно используемые рабочие процессы вызываются непосредственно из задания, а не из шагов задания.\n\n[`jobs.<job_id>.uses`](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iduses)\n\nВы ссылаетесь на повторно используемые файлы рабочих процессов с помощью одного из следующих синтаксисов:\n\n* `$/.github/workflows/{filename}` для повторного использования рабочего процесса в одном репозитории. Это рекомендуемый синтаксис для ссылки на повторно используемый рабочий процесс в одном репозитории. Этот синтаксис недоступен в GitHub Enterprise Server.\n* `{owner}/{repo}/.github/workflows/{filename}@{ref}` для повторно используемых рабочих процессов в общедоступных и частных репозиториях.\n* `./.github/workflows/{filename}` для повторно используемых рабочих процессов в одном репозитории.\n\nПри ссылке на повторно используемый рабочий процесс и `{owner}/{repo}``@{ref}`может `{ref}` быть SHA, тег выпуска или имя ветви. Если тег выпуска и ветвь имеют то же имя, тег выпуска имеет приоритет над именем ветви. Использование sha фиксации является самым безопасным вариантом для стабильности и безопасности. Дополнительные сведения см. в разделе [Справочник по безопасному использованию](/ru/actions/reference/security/secure-use#reusing-third-party-workflows).\n\nПри ссылке на повторно используемый рабочий процесс в том же репозитории или `$/``./` (без `{owner}/{repo}` и), вызываемый рабочий процесс создается из той же фиксации, что и `@{ref}`рабочий процесс вызывающего объекта. Ссылка `$/` не должна включать `@{ref}` суффикс и `$/` недоступна в GitHub Enterprise Server. Префиксы ссылок, такие как `refs/heads` и `refs/tags` не допускаются. В этом ключевом слове нельзя использовать контексты или выражения.\n\nМожно вызвать несколько рабочих процессов, ссылаясь на каждый из них в отдельном задании.\n\n```yaml\njobs:\n  call-workflow-1-in-local-repo:\n    uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89\n  call-workflow-2-in-local-repo:\n    uses: ./.github/workflows/workflow-2.yml\n  # The `$/` syntax is not available in GitHub Enterprise Server.\n  call-workflow-in-same-repo-at-running-commit:\n    uses: $/.github/workflows/workflow-2.yml\n  call-workflow-in-another-repo:\n    uses: octo-org/another-repo/.github/workflows/workflow.yml@v1\n```\n\n### Пример вызывающего рабочего процесса\n\nЭтот файл рабочего процесса вызывает два файла рабочего процесса. Второму из них, `workflow-B.yml` (показанному в [примере повторноно используемого рабочего процесса](#example-reusable-workflow)), передаются входные данные (`config-path`) и секрет (`token`).\n\n```yaml copy\nname: Call a reusable workflow\n\non:\n  pull_request:\n    branches:\n      - main\n\njobs:\n  call-workflow:\n    uses: octo-org/example-repo/.github/workflows/workflow-A.yml@v1\n\n  call-workflow-passing-data:\n    permissions:\n      contents: read\n      pull-requests: write\n    uses: octo-org/example-repo/.github/workflows/workflow-B.yml@main\n    with:\n      config-path: .github/labeler.yml\n    secrets:\n      token: ${{ secrets.GITHUB_TOKEN }}\n```\n\n## Передача входных данных и секретов в многократно используемый рабочий процесс\n\nЧтобы передать именованные входные данные в вызываемый рабочий процесс, используйте в задании ключевое слово `with`. Используйте ключевое слово `secrets` для передачи именованных секретов. Тип данных входного значения должен соответствовать типу, указанному в вызываемом рабочем процессе (логическое значение, число или строка).\n\n```yaml\njobs:\n  call-workflow-passing-data:\n    uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main\n    with:\n      config-path: .github/labeler.yml\n    secrets:\n      personal_access_token: ${{ secrets.token }}\n```\n\nРабочие процессы, которые вызывают повторно используемые рабочие процессы в одной организации или организации, могут использовать `inherit` ключевое слово для неявного передачи секретов.\n\n```yaml\njobs:\n  call-workflow-passing-data:\n    uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main\n    with:\n      config-path: .github/labeler.yml\n    secrets: inherit\n```\n\n## Использование стратегии матрицы с повторно используемым рабочим процессом\n\nЗадания, использующие стратегию матрицы, могут вызывать повторно используемый рабочий процесс.\n\nСтратегия матрицы позволяет использовать переменные в одном определении задания для автоматического создания нескольких выполнений заданий, основанных на сочетаниях переменных. Например, можно использовать стратегию матрицы для передачи различных входных данных в повторно используемый рабочий процесс. Дополнительные сведения о матрицах см. в разделе [Выполнение вариантов заданий в рабочем процессе](/ru/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations).\n\nВ этом примере задания ниже вызывается повторно используемый рабочий процесс и ссылается на контекст матрицы, определяя переменную `target` со значениями `[dev, stage, prod]`. Он будет выполнять три задания, по одному для каждого значения в переменной.\n\n```yaml copy\njobs:\n  ReusableMatrixJobForDeployment:\n    strategy:\n      matrix:\n        target: [dev, stage, prod]\n    uses: octocat/octo-repo/.github/workflows/deployment.yml@main\n    with:\n      target: ${{ matrix.target }}\n```\n\n## Вложение повторно используемых рабочих процессов\n\nМожно подключить не более десяти уровней рабочих процессов, то есть рабочий процесс вызывающего верхнего уровня и до девяти уровней повторно используемых рабочих процессов. Например: *caller-workflow\\.yml* → called-workflow-1.yml → *called-workflow-2.yml → called-workflow-3.yml* → ... \\_\\_\\_\\_*→ called-workflow-9.yml*.\n\nЦиклы в дереве рабочих процессов запрещены.\n\n> \\[!NOTE] Вложенные повторно используемые рабочие процессы требуют, чтобы все рабочие процессы в цепочке были доступны вызывающей организации, а разрешения могут поддерживаться или уменьшаться ( не повышенными) в цепочке. Дополнительные сведения см. в разделе [Повторное использовать конфигурации рабочих процессов](/ru/actions/reference/workflows-and-actions/reusing-workflow-configurations).\n\nВ рамках повторно используемых рабочих процессов можно вызвать другой повторно используемый рабочий процесс.\n\n```yaml copy\nname: Reusable workflow\n\non:\n  workflow_call:\n\njobs:\n  call-another-reusable:\n    uses: octo-org/example-repo/.github/workflows/another-reusable.yml@v1\n```\n\n## Передача секретов во вложенные рабочие процессы\n\nВы можете использовать `jobs.<job_id>.secrets` в вызывающем рабочем процессе для передачи именованных секретов в непосредственно вызываемый рабочий процесс. Кроме того, вы можете использовать `jobs.<job_id>.secrets.inherit` для передачи всех секретов вызывающего рабочего процесса в непосредственно вызываемый рабочий процесс. Дополнительные сведения см. в разделе \\[AUTOTITLE выше и справочной статье [Повторное использование рабочих процессов](/ru/actions/how-tos/reuse-automations/reuse-workflows#passing-inputs-and-secrets-to-a-reusable-workflow)]\\(/actions/reference/workflows-and-actions/workflow-syntax#jobsjob\\_idsecretsinherit). Секреты передаются только в непосредственно вызываемый рабочий процесс, поэтому в цепочке рабочих процессов A > B > C рабочий процесс C будет получать секреты от A, только если они переданы из A в B, а затем из B в C.\n\nВ следующем примере рабочий процесс A передает все секреты в рабочий процесс B, используя ключевое слово `inherit`, но рабочий процесс B передает только один секрет в рабочий процесс C. Любые другие секреты, передаваемые в рабочий процесс B, недоступны для рабочего процесса C.\n\n```yaml\njobs:\n  workflowA-calls-workflowB:\n    uses: octo-org/example-repo/.github/workflows/B.yml@main\n    secrets: inherit # pass all secrets\n```\n\n```yaml\njobs:\n  workflowB-calls-workflowC:\n    uses: different-org/example-repo/.github/workflows/C.yml@main\n    secrets:\n      repo-token: ${{ secrets.personal_access_token }} # pass just this secret\n```\n\n## Использование выходных данных из повторно используемого рабочего процесса\n\nПовторно используемый рабочий процесс может создавать данные, которые необходимо использовать в вызывающем рабочем процессе. Чтобы использовать эти выходные данные, необходимо указать их в качестве выходных данных повторно используемого рабочего процесса.\n\nЕсли повторно используемый рабочий процесс, который задает выходные данные, выполняется с помощью стратегии матрицы, выходные данные будут задаваться последним успешно завершенным повторно используемым рабочим процессом матрицы, которая фактически задает значение.\nЭто означает, что если последний успешно завершен повторно используемый рабочий процесс задает пустую строку для выходных данных, а второй успешный успешно завершенный повторно используемый рабочий процесс задает фактическое значение для выходных данных, выходные данные будут содержать значение второго последнего завершения повторно используемых рабочих процессов.\n\nВ следующем повторно используемом рабочем процессе есть одно задание, содержащее два шага. В каждом из этих шагов мы задаем одно слово в качестве выходных данных: \"hello\" и \"world\". В разделе `outputs` задания мы сопоставляем эти выходные данные шага с выходными данными задания, называемыми: `output1` и `output2`. Затем в разделе `on.workflow_call.outputs` мы определяем два набора выходных данных для самого рабочего процесса, один с именем `firstword`, который мы сопоставляем с `output1`, и один с именем `secondword`, который сопоставляем с `output2`.\n\nНеобходимо `value` задать значение выходных данных уровня задания в вызываемом рабочем процессе. Выходные данные уровня шага сначала необходимо сопоставить с выходными данными уровня задания, как показано ниже.\n\nДополнительные сведения см. в разделе \\[AUTOTITLE и [Передача сведений между заданиями](/ru/actions/how-tos/write-workflows/choose-what-workflows-do/pass-job-outputs)]\\(/actions/reference/workflows-and-actions/workflow-syntax#onworkflow\\_calloutputs).\n\n```yaml copy\nname: Reusable workflow\n\non:\n  workflow_call:\n    # Map the workflow outputs to job outputs\n    outputs:\n      firstword:\n        description: \"The first output string\"\n        value: ${{ jobs.example_job.outputs.output1 }}\n      secondword:\n        description: \"The second output string\"\n        value: ${{ jobs.example_job.outputs.output2 }}\n\njobs:\n  example_job:\n    name: Generate output\n    runs-on: ubuntu-latest\n    # Map the job outputs to step outputs\n    outputs:\n      output1: ${{ steps.step1.outputs.firstword }}\n      output2: ${{ steps.step2.outputs.secondword }}\n    steps:\n      - id: step1\n        run: echo \"firstword=hello\" >> $GITHUB_OUTPUT\n      - id: step2\n        run: echo \"secondword=world\" >> $GITHUB_OUTPUT\n```\n\nТеперь мы можем использовать выходные данные в вызывающем рабочем процессе точно так же, как вы использовали бы выходные данные задания в том же рабочем процессе. Мы ссылаемся на выходные данные, используя имена, определенные на уровне рабочего процесса в повторно используемом рабочем процессе: `firstword` и `secondword`. В этом рабочем процессе `job1` вызывает повторно используемый рабочий процесс, а `job2` печатает выходные данные многократно используемого рабочего процесса (\"hello world\") в стандартный поток вывода в журнале рабочего процесса.\n\n```yaml copy\nname: Call a reusable workflow and use its outputs\n\non:\n  workflow_dispatch:\n\njobs:\n  job1:\n    uses: octo-org/example-repo/.github/workflows/called-workflow.yml@v1\n\n  job2:\n    runs-on: ubuntu-latest\n    needs: job1\n    steps:\n      - run: echo ${{ needs.job1.outputs.firstword }} ${{ needs.job1.outputs.secondword }}\n```\n\nДополнительные сведения об использовании выходных данных задания см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idoutputs). Если вы хотите предоставить общий доступ к ней, отличной от переменной (например, артефакта сборки) между рабочими процессами, см [. раздел AUTOTITLE](/ru/actions/tutorials/store-and-share-data).\n\n## Мониторинг используемых рабочих процессов\n\nОрганизации, использующие GitHub Enterprise Cloud журнал аудита, могут взаимодействовать с GitHub помощью REST API для мониторинга используемых рабочих процессов. Для получения дополнительной информации смотрите [GitHub Enterprise Cloud документацию](/ru/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization#using-the-audit-log-api).\n\n## Следующие шаги\n\nДополнительные сведения об повторном использовании рабочих процессов см. в разделе [Повторное использовать конфигурации рабочих процессов](/ru/actions/reference/workflows-and-actions/reusing-workflow-configurations)."}