Access to reusable workflows
A reusable workflow can be used by another workflow if any of the following is true:
- Both workflows are in the same repository.
- The called workflow is stored in a public repository, and your enterprise allows you to use public reusable workflows.
- The called workflow is stored in an internal repository and the settings for that repository allow it to be accessed. For more information, see 엔터프라이즈와 작업 및 워크플로 공유.
- The called workflow is stored in a private repository and the settings for that repository allow it to be accessed. For more information, see 엔터프라이즈와 작업 및 워크플로 공유.
The following table shows the accessibility of reusable workflows to a caller workflow, depending on the visibility of the host repository.
| Caller repository | Accessible workflows repositories |
|---|---|
private | private, internal, and public |
internal | internal, and public |
public | public |
The Actions permissions on the callers repository's Actions settings page must be configured to allow the use of actions and reusable workflows - see 리포지토리에 대한 GitHub Actions 설정 관리.
For internal or private repositories, the Access policy on the Actions settings page of the called workflow's repository must be explicitly configured to allow access from repositories containing caller workflows - see 리포지토리에 대한 GitHub Actions 설정 관리.
참고 항목
보안을 강화하기 위해 GitHub Actions는 작업이나 재사용할 수 있는 워크플로의 리디렉션을 지원하지 않습니다. 즉, 소유자, 작업 리포지토리의 이름, 또는 작업 이름이 변경되면, 이전 이름으로 해당 작업을 사용하는 워크플로가 작동하지 않습니다.
Limitations
-
You can connect up to four levels of workflows. For more information, see Nesting reusable workflows.
-
You can call a maximum of 20 unique reusable workflows from a single workflow file. This limit includes any trees of nested reusable workflows that may be called starting from your top-level caller workflow file.
For example, top-level-caller-workflow.yml → called-workflow-1.yml → called-workflow-2.yml counts as 2 reusable workflows.
-
Any environment variables set in an
envcontext defined at the workflow level in the caller workflow are not propagated to the called workflow. For more information, see 변수에 정보 저장 and Contexts reference. -
Similarly, environment variables set in the
envcontext, defined in the called workflow, are not accessible in theenvcontext of the caller workflow. Instead, you must use outputs of the reusable workflow. For more information, see Using outputs from a reusable workflow. -
To reuse variables in multiple workflows, set them at the organization, repository, or environment levels and reference them using the
varscontext. For more information see 변수에 정보 저장 and Contexts reference. -
Reusable workflows are called directly within a job, and not from within a job step. You cannot, therefore, use
GITHUB_ENVto pass values to job steps in the caller workflow.
Supported keywords for jobs that call a reusable workflow
When you call a reusable workflow, you can only use the following keywords in the job containing the call:
-
참고 항목
- If
jobs.<job_id>.permissionsis not specified in the calling job, the called workflow will have the default permissions for theGITHUB_TOKEN. For more information, see GITHUB_TOKEN reference. - The
GITHUB_TOKENpermissions passed from the caller workflow can be only downgraded (not elevated) by the called workflow. - If you use
jobs.<job_id>.concurrency.cancel-in-progress: true, don't use the same value forjobs.<job_id>.concurrency.groupin the called and caller workflows as this will cause the workflow that's already running to be cancelled. A called workflow uses the name of its caller workflow in ${{ github.workflow }}, so using this context as the value ofjobs.<job_id>.concurrency.groupin both caller and called workflows will cause the caller workflow to be cancelled when the called workflow runs.
- If
How reusable workflows use runners
GitHub-hosted runners
The assignment of GitHub-hosted runners is always evaluated using only the caller's context. Billing for GitHub-hosted runners is always associated with the caller. The caller workflow cannot use GitHub-hosted runners from the called repository. For more information, see About GitHub-hosted runners.
Self-hosted runners
Called workflows that are owned by the same user or organization or enterprise as the caller workflow can access self-hosted runners from the caller's context. This means that a called workflow can access self-hosted runners that are:
- In the caller repository
- In the caller repository's organization or enterprise, provided that the runner has been made available to the caller repository
Access and permissions for nested workflows
A workflow that contains nested reusable workflows will fail if any of the nested workflows is inaccessible to the initial caller workflow. For more information, see Access to reusable workflows.
GITHUB_TOKEN permissions can only be the same or more restrictive in nested workflows. For example, in the workflow chain A > B > C, if workflow A has package: read token permission, then B and C cannot have package: write permission. For more information, see Use GITHUB_TOKEN in workflows.
For information on how to use the API to determine which workflow files were involved in a particular workflow run, see Reuse workflows.
Behavior of reusable workflows when re-running jobs
퍼블릭 리포지토리에서 재사용 가능한 워크플로는 SHA, 릴리스 태그 또는 분기 이름을 사용하여 참조할 수 있습니다. 자세한 내용은 Reuse workflows을(를) 참조하세요.
재사용 가능한 워크플로를 사용하는 워크플로를 다시 실행했으며 참조가 SHA가 아닌 경우 다음과 같은 몇 가지 동작을 주의해야 합니다.
- 워크플로에서 모든 작업을 다시 실행하면 지정된 참조에서 재사용 가능한 워크플로가 사용됩니다. 워크플로의 모든 작업을 다시 실행하는 방법에 대한 자세한 내용은 워크플로 및 작업 다시 실행을(를) 참조하세요.
- 실패한 작업 또는 워크플로의 특정 작업을 다시 실행하면 첫 번째 시도와 동일한 커밋 SHA에서 재사용 가능한 워크플로가 사용됩니다. 워크플로에서 실패한 작업을 다시 실행하는 방법에 대한 자세한 내용은 워크플로 및 작업 다시 실행을(를) 참조하세요. 워크플로에서 특정 작업을 다시 실행하는 방법에 대한 자세한 내용은 워크플로 및 작업 다시 실행을(를) 참조하세요.
github context
When a reusable workflow is triggered by a caller workflow, the github context is always associated with the caller workflow. The called workflow is automatically granted access to github.token and secrets.GITHUB_TOKEN. For more information about the github context, see Contexts reference.