Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://help.github.com/en/actions/reference/workflows-and-actions/reusable-workflows below:

Reusable workflows reference - GitHub Docs

Learn how to avoid duplication when creating a workflow by reusing existing 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 organization allows you to use public reusable workflows.
• The called workflow is stored in a private repository and the settings for that repository allow it to be accessed. For more information, see Sharing actions and workflows with your organization and Sharing actions and workflows from your private repository.

The following table shows the accessibility of reusable workflows to a caller workflow, depending on the visibility of the host repository.

The Actions permissions on the callers repository's Actions settings page must be configured to allow the use of actions and reusable workflows - see Managing GitHub Actions settings for a repository.

For 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 Managing GitHub Actions settings for a repository.

Note

To enhance security, GitHub Actions does not support redirects for actions or reusable workflows. This means that when the owner, name of an action's repository, or name of an action is changed, any workflows using that action with the previous name will fail.

• 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 env context defined at the workflow level in the caller workflow are not propagated to the called workflow. For more information, see Store information in variables and Contexts reference.

• Similarly, environment variables set in the env context, defined in the called workflow, are not accessible in the env context 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 vars context. For more information see Store information in variables and Contexts reference.

• Reusable workflows are called directly within a job, and not from within a job step. You cannot, therefore, use GITHUB_ENV to pass values to job steps in the caller workflow.

When you call a reusable workflow, you can only use the following keywords in the job containing the call:

• 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

  Note

  • If jobs.<job_id>.permissions is not specified in the calling job, the called workflow will have the default permissions for the GITHUB_TOKEN. For more information, see Workflow syntax for GitHub Actions.
  • The GITHUB_TOKEN permissions 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 for jobs.<job_id>.concurrency.group in 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 of jobs.<job_id>.concurrency.group in both caller and called workflows will cause the caller workflow to be cancelled when the called workflow runs.

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 GitHub-hosted runners.

Called workflows that are owned by the same user or organization 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, provided that the runner has been made available to the caller repository

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 for authentication 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.

Reusable workflows from public repositories can be referenced using a SHA, a release tag, or a branch name. For more information, see Reuse workflows.

When you re-run a workflow that uses a reusable workflow and the reference is not a SHA, there are some behaviors to be aware of:

• Re-running all jobs in a workflow will use the reusable workflow from the specified reference. For more information about re-running all jobs in a workflow, see Re-running workflows and jobs.
• Re-running failed jobs or a specific job in a workflow will use the reusable workflow from the same commit SHA of the first attempt. For more information about re-running failed jobs in a workflow, see Re-running workflows and jobs. For more information about re-running a specific job in a workflow, see Re-running workflows and jobs.

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.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4