jprdonnelly/docs
1
0
Fork 0
mirror of synced 2025-12-22 11:26:57 -05:00
Code Issues Projects Releases Wiki Activity

Add new categories: "workflows" and "jobs". Add new articles for jobs. (#22898)

Browse Source
This commit is contained in:
Martin Lopes
2022-01-17 16:45:57 +10:00
committed by GitHub
parent 31fea5f4d5
commit 2a58d29f33
93 changed files with 1252 additions and 15892 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
content/actions/index.md
View File

@@ -46,6 +46,8 @@ versions:
children:
- /quickstart
- /learn-github-actions
- /using-workflows
- /using-jobs
- /managing-workflow-runs
- /automating-builds-and-tests
- /deployment

24
content/actions/learn-github-actions/index.md
View File

@@ -4,25 +4,15 @@ shortTitle: Learn GitHub Actions
intro: 'Whether you are new to {% data variables.product.prodname_actions %} or interested in learning all they have to offer, this guide will help you use {% data variables.product.prodname_actions %} to accelerate your application development workflows.'
redirect_from:
- /articles/about-github-actions
- /github/automating-your-workflow-with-github-actions/about-github-actions
- /actions/automating-your-workflow-with-github-actions/about-github-actions
- /actions/getting-started-with-github-actions
- /actions/getting-started-with-github-actions/about-github-actions
- /actions/getting-started-with-github-actions/overview
- /actions/getting-started-with-github-actions/getting-started-with-github-actions
- /actions/configuring-and-managing-workflows/configuring-a-workflow
- /articles/creating-a-workflow-with-github-actions
- /articles/configuring-a-workflow
- /github/automating-your-workflow-with-github-actions/configuring-a-workflow
- /actions/automating-your-workflow-with-github-actions/configuring-a-workflow
- /actions/creating-workflows/workflow-configuration-options
- /articles/configuring-workflows
- /github/automating-your-workflow-with-github-actions/configuring-workflows
- /actions/automating-your-workflow-with-github-actions/configuring-workflows
- /articles/getting-started-with-github-actions
- /github/automating-your-workflow-with-github-actions/about-github-actions
- /actions/automating-your-workflow-with-github-actions/about-github-actions
- /github/automating-your-workflow-with-github-actions/getting-started-with-github-actions
- /actions/automating-your-workflow-with-github-actions/getting-started-with-github-actions
- /actions/configuring-and-managing-workflows
- /articles/getting-started-with-github-actions
versions:
fpt: '*'
ghes: '*'
@@ -32,16 +22,8 @@ children:
- /understanding-github-actions
- /finding-and-customizing-actions
- /essential-features-of-github-actions
- /managing-complex-workflows
- /sharing-workflows-secrets-and-runners-with-your-organization
- /creating-starter-workflows-for-your-organization
- /using-starter-workflows
- /reusing-workflows
- /events-that-trigger-workflows
- /expressions
- /contexts
- /workflow-syntax-for-github-actions
- /workflow-commands-for-github-actions
- /environment-variables
- /usage-limits-billing-and-administration
---

186
content/actions/learn-github-actions/managing-complex-workflows.md
View File

@@ -1,186 +0,0 @@
---
title: Managing complex workflows
shortTitle: Managing complex workflows
intro: 'This guide shows you how to use the advanced features of {% data variables.product.prodname_actions %}, with secret management, dependent jobs, caching, build matrices,{% ifversion fpt or ghes > 3.0 or ghae or ghec %} environments,{% endif %} and labels.'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: how_to
topics:
- Workflows
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Overview
This article describes some of the advanced features of {% data variables.product.prodname_actions %} that help you create more complex workflows.
## Storing secrets
If your workflows use sensitive data, such as passwords or certificates, you can save these in {% data variables.product.prodname_dotcom %} as _secrets_ and then use them in your workflows as environment variables. This means that you will be able to create and share workflows without having to embed sensitive values directly in the YAML workflow.
This example action demonstrates how to reference an existing secret as an environment variable, and send it as a parameter to an example command.
{% raw %}
```yaml
jobs:
example-job:
runs-on: ubuntu-latest
steps:
- name: Retrieve secret
env:
super_secret: ${{ secrets.SUPERSECRET }}
run: |
example-command "$super_secret"
```
{% endraw %}
For more information, see "[Creating and storing encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)."
## Creating dependent jobs
By default, the jobs in your workflow all run in parallel at the same time. So if you have a job that must only run after another job has completed, you can use the `needs` keyword to create this dependency. If one of the jobs fails, all dependent jobs are skipped; however, if you need the jobs to continue, you can define this using the [`if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif) conditional statement.
In this example, the `setup`, `build`, and `test` jobs run in series, with `build` and `test` being dependent on the successful completion of the job that precedes them:
```yaml
jobs:
setup:
runs-on: ubuntu-latest
steps:
- run: ./setup_server.sh
build:
needs: setup
runs-on: ubuntu-latest
steps:
- run: ./build_server.sh
test:
needs: build
runs-on: ubuntu-latest
steps:
- run: ./test_server.sh
```
For more information, see [`jobs.<job_id>.needs`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds).
## Using a build matrix
You can use a build matrix if you want your workflow to run tests across multiple combinations of operating systems, platforms, and languages. The build matrix is created using the `strategy` keyword, which receives the build options as an array. For example, this build matrix will run the job multiple times, using different versions of Node.js:
{% raw %}
```yaml
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node: [6, 8, 10]
steps:
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node }}
```
{% endraw %}
For more information, see [`jobs.<job_id>.strategy.matrix`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix).
{% ifversion fpt or ghec %}
## Caching dependencies
{% data variables.product.prodname_dotcom %}-hosted runners are started as fresh environments for each job, so if your jobs regularly reuse dependencies, you can consider caching these files to help improve performance. Once the cache is created, it is available to all workflows in the same repository.
This example demonstrates how to cache the ` ~/.npm` directory:
{% raw %}
```yaml
jobs:
example-job:
steps:
- name: Cache node modules
uses: actions/cache@v2
env:
cache-name: cache-node-modules
with:
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
```
{% endraw %}
For more information, see "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching dependencies to speed up workflows</a>."
{% endif %}
## Using databases and service containers
If your job requires a database or cache service, you can use the [`services`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idservices) keyword to create an ephemeral container to host the service; the resulting container is then available to all steps in that job and is removed when the job has completed. This example demonstrates how a job can use `services` to create a `postgres` container, and then use `node` to connect to the service.
```yaml
jobs:
container-job:
runs-on: ubuntu-latest
container: node:10.18-jessie
services:
postgres:
image: postgres
steps:
- name: Check out repository code
uses: actions/checkout@v2
- name: Install dependencies
run: npm ci
- name: Connect to PostgreSQL
run: node client.js
env:
POSTGRES_HOST: postgres
POSTGRES_PORT: 5432
```
For more information, see "[Using databases and service containers](/actions/configuring-and-managing-workflows/using-databases-and-service-containers)."
## Using labels to route workflows
This feature helps you assign jobs to a specific hosted runner. If you want to be sure that a particular type of runner will process your job, you can use labels to control where jobs are executed. You can assign labels to a self-hosted runner in addition to their default label of `self-hosted`. Then, you can refer to these labels in your YAML workflow, ensuring that the job is routed in a predictable way.{% ifversion not ghae %} {% data variables.product.prodname_dotcom %}-hosted runners have predefined labels assigned.{% endif %}
This example shows how a workflow can use labels to specify the required runner:
```yaml
jobs:
example-job:
runs-on: [self-hosted, linux, x64, gpu]
```
A workflow will only run on a runner that has all the labels in the `runs-on` array. The job will preferentially go to an idle self-hosted runner with the specified labels. If none are available and a {% data variables.product.prodname_dotcom %}-hosted runner with the specified labels exists, the job will go to a {% data variables.product.prodname_dotcom %}-hosted runner.
To learn more about self-hosted runner labels, see ["Using labels with self-hosted runners](/actions/hosting-your-own-runners/using-labels-with-self-hosted-runners)."
{% ifversion fpt or ghes %}
To learn more about {% data variables.product.prodname_dotcom %}-hosted runner labels, see ["Supported runners and hardware resources"](/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources).
{% endif %}
{% data reusables.actions.reusable-workflows %}
{% ifversion fpt or ghes > 3.0 or ghae or ghec %}
## Using environments
You can configure environments with protection rules and secrets. Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. For more information, see "[Using environments for deployment](/actions/deployment/using-environments-for-deployment)."
{% endif %}
## Using starter workflows
{% data reusables.actions.workflow-template-overview %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.actions-tab %}
1. If your repository already has existing workflows: In the upper-left corner, click **New workflow**.
![Create a new workflow](/assets/images/help/repository/actions-new-workflow.png)
1. Under the name of the starter workflow you'd like to use, click **Set up this workflow**.
![Set up this workflow](/assets/images/help/settings/actions-create-starter-workflow.png)
## Next steps
To continue learning about {% data variables.product.prodname_actions %}, see "[Sharing workflows, secrets, and runners with your organization](/actions/learn-github-actions/sharing-workflows-secrets-and-runners-with-your-organization)."

6
content/actions/learn-github-actions/understanding-github-actions.md
View File

@@ -42,6 +42,8 @@ Your repository can have multiple workflows in a repository, each of which can p
{% ifversion fpt or ghes > 3.3 or ghae-issue-4757 or ghec %}You can reference a workflow within another workflow, see "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)."{% endif %}
For more information about workflows, see "[Using workflows](/actions/using-workflows)."
### Events
An event is a specific activity in a repository that triggers a workflow run. For example, activity can originate from {% data variables.product.prodname_dotcom %} when someone creates a pull request, opens an issue, or pushes a commit to a repository. You can also trigger a workflow run on a schedule, by [posting to a REST API](/rest/reference/repos#create-a-repository-dispatch-event), or manually.
@@ -54,12 +56,16 @@ A job is a set of _steps_ in a workflow that execute on the same runner. Each s
You can configure a job's dependencies with other jobs; by default, jobs have no dependencies and run in parallel with each other. When a job takes a dependency on another job, it will wait for the dependent job to complete before it can run. For example, you may have multiple build jobs for different architectures that have no dependencies, and a packaging job that is dependent on those jobs. The build jobs will run in parallel, and when they have all completed successfully, the packaging job will run.
For more information about jobs, see "[Using jobs](/actions/using-jobs)."
### Actions
An _action_ is a custom application for the {% data variables.product.prodname_actions %} platform that performs a complex but frequently repeated task. Use an action to help reduce the amount of repetitive code that you write in your workflow files. An action can pull your git repository from {% data variables.product.prodname_dotcom %}, set up the correct toolchain for your build environment, or set up the authentication to your cloud provider.
You can write your own actions, or you can find actions to use in your workflows in the {% data variables.product.prodname_marketplace %}.
For more information, see "[Creating actions](/actions/creating-actions)."
### Runners
{% data reusables.actions.about-runners %} Each runner can run a single job at a time. {% ifversion ghes or ghae %} You must host your own runners for {% data variables.product.product_name %}. {% elsif fpt or ghec %}{% data variables.product.company_short %} provides Ubuntu Linux, Microsoft Windows, and macOS runners to run your workflows; each workflow run executes in a fresh, newly-provisioned virtual machine. If you need a different operating system or require a specific hardware configuration, you can host your own runners.{% endif %} For more information{% ifversion fpt or ghec %} about self-hosted runners{% endif %}, see "[Hosting your own runners](/actions/hosting-your-own-runners)."

1706
content/actions/learn-github-actions/workflow-syntax-for-github-actions.md
View File

File diff suppressed because it is too large Load Diff

22
content/actions/using-jobs/assigning-permissions-to-jobs.md Normal file
View File

@@ -0,0 +1,22 @@
---
title: Assigning permissions to jobs
shortTitle: Assigning permissions to jobs
intro: Modify the default permissions granted to `GITHUB_TOKEN`.
versions:
fpt: '*'
ghes: '> 3.1'
ghae: 'ghae-next'
ghec: '*'
miniTocMaxHeadingLevel: 4
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Overview
{% data reusables.actions.jobs.section-assigning-permissions-to-jobs %}
## Assigning permissions to a specific job
{% data reusables.actions.jobs.section-assigning-permissions-to-jobs-specific %}

18
content/actions/using-jobs/choosing-the-runner-for-a-job.md Normal file
View File

@@ -0,0 +1,18 @@
---
title: Choosing the runner for a job
shortTitle: Choosing the runner for a job
intro: Define the type of machine that will process a job in your workflow.
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
miniTocMaxHeadingLevel: 4
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Overview
{% data reusables.actions.jobs.section-choosing-the-runner-for-a-job %}

18
content/actions/using-jobs/defining-outputs-for-jobs.md Normal file
View File

@@ -0,0 +1,18 @@
---
title: Defining outputs for jobs
shortTitle: Defining outputs for jobs
intro: Create a map of outputs for your jobs.
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
miniTocMaxHeadingLevel: 4
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Overview
{% data reusables.actions.jobs.section-defining-outputs-for-jobs %}

23
content/actions/using-jobs/index.md Normal file
View File

@@ -0,0 +1,23 @@
---
title: Using jobs
shortTitle: Using jobs
intro: 'Creating and managing {% data variables.product.prodname_actions %} jobs.'
redirect_from:
- /actions/jobs
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
children:
- /using-jobs-in-a-workflow
- /choosing-the-runner-for-a-job
- /using-conditions-to-control-job-execution
- /using-a-build-matrix-for-your-jobs
- /using-concurrency
- /using-environments-for-jobs
- /running-jobs-in-a-container
- /setting-default-values-for-jobs
- /assigning-permissions-to-jobs
- /defining-outputs-for-jobs
---

43
content/actions/using-jobs/running-jobs-in-a-container.md Normal file
View File

@@ -0,0 +1,43 @@
---
title: Running jobs in a container
shortTitle: Running jobs in a container
intro: Use a container to run the steps in a job.
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
miniTocMaxHeadingLevel: 4
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Overview
{% data reusables.actions.jobs.section-running-jobs-in-a-container %}
## Defining the container image
{% data reusables.actions.jobs.section-running-jobs-in-a-container-image %}
## Defining credentials for a container registry
{% data reusables.actions.jobs.section-running-jobs-in-a-container-credentials %}
## Using environment variables with a container
{% data reusables.actions.jobs.section-running-jobs-in-a-container-env %}
## Exposing network ports on a container
{% data reusables.actions.jobs.section-running-jobs-in-a-container-ports %}
## Mounting volumes in a container
{% data reusables.actions.jobs.section-running-jobs-in-a-container-volumes %}
## Setting container resource options
{% data reusables.actions.jobs.section-running-jobs-in-a-container-options %}

30
content/actions/using-jobs/setting-default-values-for-jobs.md Normal file
View File

@@ -0,0 +1,30 @@
---
title: Setting default values for jobs
shortTitle: Setting default values for jobs
intro: Define the default settings that will apply to all jobs in the workflow, or all steps in a job.
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
miniTocMaxHeadingLevel: 4
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Overview
{% data reusables.actions.jobs.setting-default-values-for-jobs-defaults %}
## Setting default shell and working directory
{% data reusables.actions.jobs.setting-default-values-for-jobs-defaults-run %}
## Setting default values for a specific job
{% data reusables.actions.jobs.setting-default-values-for-jobs-defaults-job %}
## Setting default shell and working directory for a job
{% data reusables.actions.jobs.setting-default-values-for-jobs-defaults-job-run %}

30
content/actions/using-jobs/using-a-build-matrix-for-your-jobs.md Normal file
View File

@@ -0,0 +1,30 @@
---
title: Using a build matrix for your jobs
shortTitle: Using a build matrix for your jobs
intro: Create a build matrix and define variations for each job.
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
miniTocMaxHeadingLevel: 4
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Overview
{% data reusables.actions.jobs.section-using-a-build-matrix-for-your-jobs-strategy %}
## Creating a matrix of different job configurations
{% data reusables.actions.jobs.section-using-a-build-matrix-for-your-jobs-matrix %}
## Canceling remaining jobs if a `matrix` job fails
{% data reusables.actions.jobs.section-using-a-build-matrix-for-your-jobs-failfast %}
## Defining the maximum number of concurrent jobs in a `matrix`
{% data reusables.actions.jobs.section-using-a-build-matrix-for-your-jobs-max-parallel %}

19
content/actions/using-jobs/using-concurrency.md Normal file
View File

@@ -0,0 +1,19 @@
---
title: Using concurrency
shortTitle: Using concurrency
intro: Run a single job at a time.
versions:
fpt: '*'
ghes: '> 3.1'
ghae: 'ghae-next'
ghec: '*'
miniTocMaxHeadingLevel: 4
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Overview
{% data reusables.actions.jobs.section-using-concurrency-jobs %}

18
content/actions/using-jobs/using-conditions-to-control-job-execution.md Normal file
View File

@@ -0,0 +1,18 @@
---
title: Using conditions to control job execution
shortTitle: Using conditions to control job execution
intro: Prevent a job from running unless your conditions are met.
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
miniTocMaxHeadingLevel: 4
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Overview
{% data reusables.actions.jobs.section-using-conditions-to-control-job-execution %}

18
content/actions/using-jobs/using-environments-for-jobs.md Normal file
View File

@@ -0,0 +1,18 @@
---
title: Using environments for jobs
shortTitle: Using environments for jobs
intro: Specify an environment for a job.
versions:
fpt: '*'
ghes: '> 3.0'
ghae: '*'
ghec: '*'
miniTocMaxHeadingLevel: 4
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Overview
{% data reusables.actions.jobs.section-using-environments-for-jobs %}

30
content/actions/using-jobs/using-jobs-in-a-workflow.md Normal file
View File

@@ -0,0 +1,30 @@
---
title: Using jobs in a workflow
shortTitle: Using jobs in a workflow
intro: Use workflows to run multiple jobs.
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
miniTocMaxHeadingLevel: 4
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Overview
{% data reusables.actions.jobs.section-using-jobs-in-a-workflow %}
## Setting an ID for a job
{% data reusables.actions.jobs.section-using-jobs-in-a-workflow-id %}
## Setting a name for a job
{% data reusables.actions.jobs.section-using-jobs-in-a-workflow-name %}
## Defining prerequisite jobs
{% data reusables.actions.jobs.section-using-jobs-in-a-workflow-needs %}

15
translations/pt-BR/content/actions/learn-github-actions/managing-complex-workflows.md → content/actions/using-workflows/advanced-workflow-features.md
View File

@@ -1,7 +1,9 @@
---
title: Managing complex workflows
shortTitle: Managing complex workflows
title: Advanced workflow features
shortTitle: Advanced workflow features
intro: 'This guide shows you how to use the advanced features of {% data variables.product.prodname_actions %}, with secret management, dependent jobs, caching, build matrices,{% ifversion fpt or ghes > 3.0 or ghae or ghec %} environments,{% endif %} and labels.'
redirect_from:
- /actions/learn-github-actions/managing-complex-workflows
versions:
fpt: '*'
ghes: '*'
@@ -10,6 +12,7 @@ versions:
type: how_to
topics:
- Workflows
miniTocMaxHeadingLevel: 4
---
{% data reusables.actions.enterprise-beta %}
@@ -43,7 +46,7 @@ For more information, see "[Creating and storing encrypted secrets](/actions/con
## Creating dependent jobs
By default, the jobs in your workflow all run in parallel at the same time. So if you have a job that must only run after another job has completed, you can use the `needs` keyword to create this dependency. If one of the jobs fails, all dependent jobs are skipped; however, if you need the jobs to continue, you can define this using the [`if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif) conditional statement.
By default, the jobs in your workflow all run in parallel at the same time. So if you have a job that must only run after another job has completed, you can use the `needs` keyword to create this dependency. If one of the jobs fails, all dependent jobs are skipped; however, if you need the jobs to continue, you can define this using the [`if`](/actions/using-jobs/using-conditions-to-control-job-execution) conditional statement.
In this example, the `setup`, `build`, and `test` jobs run in series, with `build` and `test` being dependent on the successful completion of the job that precedes them:
@@ -65,7 +68,7 @@ jobs:
- run: ./test_server.sh
```
For more information, see [`jobs.<job_id>.needs`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds).
For more information, see "[Defining prerequisite jobs](/actions/using-jobs/using-jobs-in-a-workflow#defining-prerequisite-jobs)."
## Using a build matrix
@@ -86,7 +89,7 @@ jobs:
```
{% endraw %}
For more information, see [`jobs.<job_id>.strategy.matrix`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix).
For more information, see "[Using a build matrix for your jobs](/actions/using-jobs/using-a-build-matrix-for-your-jobs)."
{% ifversion fpt or ghec %}
## Caching dependencies
@@ -117,7 +120,7 @@ For more information, see "<a href="/actions/guides/caching-dependencies-to-spee
## Using databases and service containers
If your job requires a database or cache service, you can use the [`services`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idservices) keyword to create an ephemeral container to host the service; the resulting container is then available to all steps in that job and is removed when the job has completed. This example demonstrates how a job can use `services` to create a `postgres` container, and then use `node` to connect to the service.
If your job requires a database or cache service, you can use the [`services`](/actions/using-jobs/running-jobs-in-a-container) keyword to create an ephemeral container to host the service; the resulting container is then available to all steps in that job and is removed when the job has completed. This example demonstrates how a job can use `services` to create a `postgres` container, and then use `node` to connect to the service.
```yaml
jobs:

3
content/actions/learn-github-actions/creating-starter-workflows-for-your-organization.md → content/actions/using-workflows/creating-starter-workflows-for-your-organization.md
View File

@@ -5,6 +5,7 @@ intro: Learn how you can create starter workflows to help people in your team ad
redirect_from:
- /actions/configuring-and-managing-workflows/sharing-workflow-templates-within-your-organization
- /actions/learn-github-actions/creating-workflow-templates
- /actions/learn-github-actions/creating-starter-workflows-for-your-organization
versions:
fpt: '*'
ghes: '*'
@@ -96,4 +97,4 @@ To add another starter workflow, add your files to the same `workflow-templates`
## Next steps
To continue learning about {% data variables.product.prodname_actions %}, see "[Using starter workflows](/actions/learn-github-actions/using-starter-workflows)."
To continue learning about {% data variables.product.prodname_actions %}, see "[Using starter workflows](/actions/using-workflows/using-starter-workflows)."

1
content/actions/learn-github-actions/events-that-trigger-workflows.md → content/actions/using-workflows/events-that-trigger-workflows.md
View File

@@ -7,6 +7,7 @@ redirect_from:
- /github/automating-your-workflow-with-github-actions/events-that-trigger-workflows
- /actions/automating-your-workflow-with-github-actions/events-that-trigger-workflows
- /actions/reference/events-that-trigger-workflows
- /actions/learn-github-actions/events-that-trigger-workflows
versions:
fpt: '*'
ghes: '*'

32
content/actions/using-workflows/index.md Normal file
View File

@@ -0,0 +1,32 @@
---
title: Using workflows
shortTitle: Using workflows
intro: 'Creating and managing {% data variables.product.prodname_actions %} workflows.'
redirect_from:
- /actions/configuring-and-managing-workflows/configuring-a-workflow
- /articles/creating-a-workflow-with-github-actions
- /articles/configuring-a-workflow
- /github/automating-your-workflow-with-github-actions/configuring-a-workflow
- /actions/automating-your-workflow-with-github-actions/configuring-a-workflow
- /actions/creating-workflows/workflow-configuration-options
- /articles/configuring-workflows
- /github/automating-your-workflow-with-github-actions/configuring-workflows
- /actions/automating-your-workflow-with-github-actions/configuring-workflows
- /actions/configuring-and-managing-workflows
- /actions/workflows
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
children:
- /triggering-a-workflow
- /events-that-trigger-workflows
- /workflow-syntax-for-github-actions
- /workflow-commands-for-github-actions
- /reusing-workflows
- /advanced-workflow-features
- /creating-starter-workflows-for-your-organization
- /using-starter-workflows
- /sharing-workflows-secrets-and-runners-with-your-organization
---

6
content/actions/learn-github-actions/reusing-workflows.md → content/actions/using-workflows/reusing-workflows.md
View File

@@ -2,6 +2,8 @@
title: Reusing workflows
shortTitle: Reusing workflows
intro: Learn how to avoid duplication when creating a workflow by reusing existing workflows.
redirect_from:
- /actions/learn-github-actions/reusing-workflows
miniTocMaxHeadingLevel: 3
versions:
fpt: '*'
@@ -32,9 +34,9 @@ If you reuse a workflow from a different repository, any actions in the called w
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 "[Context and expression syntax for GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)."
### Reusable workflows and starter workflow
### Reusable workflows and starter workflows
Starter workflow allow everyone in your organization who has permission to create workflows to do so more quickly and easily. When people create a new workflow, they can choose a starter workflow and some or all of the work of writing the workflow will be done for them. Inside starter workflow, you can also reference reusable workflows to make it easy for people to benefit from reusing centrally managed workflow code. If you use a tag or branch name when referencing the reusable workflow then you can ensure that everyone who reuses that workflow will always be using the same YAML code. However, if you reference a reusable workflow by a tag or branch, be sure that you can trust that version of the workflow. For more information, see "[Security hardening for {% data variables.product.prodname_actions %}](/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows)."
Starter workflows allow everyone in your organization who has permission to create workflows to do so more quickly and easily. When people create a new workflow, they can choose a starter workflow and some or all of the work of writing the workflow will be done for them. Within a starter workflow, you can also reference reusable workflows to make it easy for people to benefit from reusing centrally managed workflow code. If you use a tag or branch name when referencing the reusable workflow, you can ensure that everyone who reuses that workflow will always be using the same YAML code. However, if you reference a reusable workflow by a tag or branch, be sure that you can trust that version of the workflow. For more information, see "[Security hardening for {% data variables.product.prodname_actions %}](/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows)."
For more information, see "[Creating starter workflows for your organization](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)."

9
content/actions/learn-github-actions/sharing-workflows-secrets-and-runners-with-your-organization.md → content/actions/using-workflows/sharing-workflows-secrets-and-runners-with-your-organization.md
View File

@@ -1,9 +1,10 @@
---
title: 'Sharing workflows, secrets, and runners with your organization'
shortTitle: Sharing workflows with your organization
intro: 'Learn how you can use organization features to collaborate with your team, by sharing starter workflow, secrets, and self-hosted runners.'
intro: 'Learn how you can use organization features to collaborate with your team, by sharing starter workflows, secrets, and self-hosted runners.'
redirect_from:
- /actions/learn-github-actions/sharing-workflows-with-your-organization
- /actions/learn-github-actions/sharing-workflows-secrets-and-runners-with-your-organization
versions:
fpt: '*'
ghes: '*'
@@ -17,11 +18,11 @@ type: how_to
## Overview
If you need to share workflows and other {% data variables.product.prodname_actions %} features with your team, then consider collaborating within a {% data variables.product.prodname_dotcom %} organization. An organization allows you to centrally store and manage secrets, artifacts, and self-hosted runners. You can also create starter workflow in the `.github` repository and share them with other users in your organization.
If you need to share workflows and other {% data variables.product.prodname_actions %} features with your team, then consider collaborating within a {% data variables.product.prodname_dotcom %} organization. An organization allows you to centrally store and manage secrets, artifacts, and self-hosted runners. You can also create starter workflows in the `.github` repository and share them with other users in your organization.
## Using starter workflows
{% data reusables.actions.workflow-organization-templates %} For more information, see "[Creating starter workflows for your organization](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)."
{% data reusables.actions.workflow-organization-templates %} For more information, see "[Creating starter workflows for your organization](/actions/using-workflows/creating-starter-workflows-for-your-organization)."
{% data reusables.actions.reusable-workflows %}
@@ -51,4 +52,4 @@ For more information, see "[Managing access to self-hosted runners using groups]
## Next steps
To continue learning about {% data variables.product.prodname_actions %}, see "[Creating starter workflows for your organization](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)."
To continue learning about {% data variables.product.prodname_actions %}, see "[Creating starter workflows for your organization](/actions/using-workflows/creating-starter-workflows-for-your-organization)."

47
content/actions/using-workflows/triggering-a-workflow.md Normal file
View File

@@ -0,0 +1,47 @@
---
title: Triggering a workflow
shortTitle: Triggering a workflow
intro: 'How to automatically trigger {% data variables.product.prodname_actions %} workflows'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- Workflows
- CI
- CD
miniTocMaxHeadingLevel: 4
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Overview
{% data reusables.actions.workflows.section-triggering-a-workflow %}
## Defining event types
{% data reusables.actions.workflows.section-triggering-a-workflow-types %}
## Targeting specific branches
{% data reusables.actions.workflows.section-triggering-a-workflow-branches %}
## Running on specific branches or tags
{% data reusables.actions.workflows.section-run-on-specific-branches-or-tags %}
## Specifying which branches the workflow can run on
{% data reusables.actions.workflows.section-specifying-branches %}
## Using specific file paths
{% data reusables.actions.workflows.section-triggering-a-workflow-paths %}
## Using a schedule
{% data reusables.actions.workflows.section-triggering-a-workflow-schedule %}

1
content/actions/learn-github-actions/using-starter-workflows.md → content/actions/using-workflows/using-starter-workflows.md
View File

@@ -8,6 +8,7 @@ redirect_from:
- /actions/building-and-testing-code-with-continuous-integration/setting-up-continuous-integration-using-github-actions
- /actions/guides/setting-up-continuous-integration-using-workflow-templates
- /actions/learn-github-actions/using-workflow-templates
- /actions/learn-github-actions/using-starter-workflows
versions:
fpt: '*'
ghes: '*'

1
content/actions/learn-github-actions/workflow-commands-for-github-actions.md → content/actions/using-workflows/workflow-commands-for-github-actions.md
View File

@@ -9,6 +9,7 @@ redirect_from:
- /actions/reference/development-tools-for-github-actions
- /actions/reference/logging-commands-for-github-actions
- /actions/reference/workflow-commands-for-github-actions
- /actions/learn-github-actions/workflow-commands-for-github-actions
versions:
fpt: '*'
ghes: '*'

786
translations/es-ES/content/actions/learn-github-actions/workflow-syntax-for-github-actions.md → content/actions/using-workflows/workflow-syntax-for-github-actions.md
View File

File diff suppressed because it is too large Load Diff

4
data/reusables/actions/actions-group-concurrency.md
View File

@@ -1,6 +1,6 @@
When a concurrent job or workflow is queued, if another job or workflow using the same concurrency group in the repository is in progress, the queued job or workflow will be `pending`. Any previously pending job or workflow in the concurrency group will be canceled. To also cancel any currently running job or workflow in the same concurrency group, specify `cancel-in-progress: true`.
## Examples: Using concurrency and the default behavior
### Examples: Using concurrency and the default behavior
{% raw %}
```yaml
@@ -14,7 +14,7 @@ concurrency: ci-${{ github.ref }}
```
{% endraw %}
## Example: Using concurrency to cancel any in-progress job or run
### Example: Using concurrency to cancel any in-progress job or run
{% raw %}
```yaml

23
data/reusables/actions/jobs/section-assigning-permissions-to-jobs-specific.md Normal file
View File

@@ -0,0 +1,23 @@
For a specific job, you can use `jobs.<job_id>.permissions` to modify the default permissions granted to the `GITHUB_TOKEN`, adding or removing access as required, so that you only allow the minimum required access. For more information, see "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)."
By specifying the permission within a job definition, you can configure a different set of permissions for the `GITHUB_TOKEN` for each job, if required. Alternatively, you can specify the permissions for all jobs in the workflow. For information on defining permissions at the workflow level, see [`permissions`](/actions/using-workflows/workflow-syntax-for-github-actions#permissions).
{% data reusables.github-actions.github-token-available-permissions %}
{% data reusables.github-actions.forked-write-permission %}
#### Example: Setting permissions for a specific job
This example shows permissions being set for the `GITHUB_TOKEN` that will only apply to the job named `stale`. Write access is granted for the `issues` and `pull-requests` scopes. All other scopes will have no access.
```yaml
jobs:
stale:
runs-on: ubuntu-latest
permissions:
issues: write
pull-requests: write
steps:
- uses: actions/stale@v3
```

21
data/reusables/actions/jobs/section-assigning-permissions-to-jobs.md Normal file
View File

@@ -0,0 +1,21 @@
You can use `permissions` to modify the default permissions granted to the `GITHUB_TOKEN`, adding or removing access as required, so that you only allow the minimum required access. For more information, see "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)."
You can use `permissions` either as a top-level key, to apply to all jobs in the workflow, or within specific jobs. When you add the `permissions` key within a specific job, all actions and run commands within that job that use the `GITHUB_TOKEN` gain the access rights you specify. For more information, see [`jobs.<job_id>.permissions`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions).
{% data reusables.github-actions.github-token-available-permissions %}
{% data reusables.github-actions.forked-write-permission %}
### Example: Assigning permissions to GITHUB_TOKEN
This example shows permissions being set for the `GITHUB_TOKEN` that will apply to all jobs in the workflow. All permissions are granted read access.
```yaml
name: "My workflow"
on: [ push ]
permissions: read-all
jobs:
...
```

38
data/reusables/actions/jobs/section-choosing-the-runner-for-a-job.md Normal file
View File

@@ -0,0 +1,38 @@
Use `jobs.<job_id>.runs-on` to define the type of machine to run the job on. {% ifversion fpt or ghec %}The machine can be either a {% data variables.product.prodname_dotcom %}-hosted runner or a self-hosted runner.{% endif %} You can provide `runs-on` as a single string or as an array of strings. If you specify an array of strings, your workflow will run on a self-hosted runner whose labels match all of the specified `runs-on` values, if available. If you would like to run your workflow on multiple machines, use [`jobs.<job_id>.strategy`](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategy).
{% ifversion fpt or ghec or ghes %}
{% data reusables.actions.enterprise-github-hosted-runners %}
### Choosing {% data variables.product.prodname_dotcom %}-hosted runners
If you use a {% data variables.product.prodname_dotcom %}-hosted runner, each job runs in a fresh instance of a virtual environment specified by `runs-on`.
Available {% data variables.product.prodname_dotcom %}-hosted runner types are:
{% data reusables.github-actions.supported-github-runners %}
#### Example: Specifying an operating system
```yaml
runs-on: ubuntu-latest
```
For more information, see "[Virtual environments for {% data variables.product.prodname_dotcom %}-hosted runners](/github/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners)."
{% endif %}
{% ifversion fpt or ghec or ghes %}
### Choosing self-hosted runners
{% endif %}
{% data reusables.actions.ae-self-hosted-runners-notice %}
{% data reusables.github-actions.self-hosted-runner-labels-runs-on %}
#### Example: Using labels for runner selection
```yaml
runs-on: [self-hosted, linux]
```
For more information, see "[About self-hosted runners](/github/automating-your-workflow-with-github-actions/about-self-hosted-runners)" and "[Using self-hosted runners in a workflow](/github/automating-your-workflow-with-github-actions/using-self-hosted-runners-in-a-workflow)."

29
data/reusables/actions/jobs/section-defining-outputs-for-jobs.md Normal file
View File

@@ -0,0 +1,29 @@
You can use `jobs.<job_id>.outputs` to create a `map` of outputs for a job. Job outputs are available to all downstream jobs that depend on this job. For more information on defining job dependencies, see [`jobs.<job_id>.needs`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds).
Job outputs are strings, and job outputs containing expressions are evaluated on the runner at the end of each job. Outputs containing secrets are redacted on the runner and not sent to {% data variables.product.prodname_actions %}.
To use job outputs in a dependent job, you can use the `needs` context. For more information, see "[Contexts](/actions/learn-github-actions/contexts#needs-context)."
### Example: Defining outputs for a job
{% raw %}
```yaml
jobs:
job1:
runs-on: ubuntu-latest
# Map a step output to a job output
outputs:
output1: ${{ steps.step1.outputs.test }}
output2: ${{ steps.step2.outputs.test }}
steps:
- id: step1
run: echo "::set-output name=test::hello"
- id: step2
run: echo "::set-output name=test::world"
job2:
runs-on: ubuntu-latest
needs: job1
steps:
- run: echo ${{needs.job1.outputs.output1}} ${{needs.job1.outputs.output2}}
```
{% endraw %}

13
data/reusables/actions/jobs/section-running-jobs-in-a-container-credentials.md Normal file
View File

@@ -0,0 +1,13 @@
{% data reusables.actions.registry-credentials %}
#### Example: Defining credentials for a container registry
{% raw %}
```yaml
container:
image: ghcr.io/owner/image
credentials:
username: ${{ github.actor }}
password: ${{ secrets.ghcr_token }}
```
{% endraw %}

1
data/reusables/actions/jobs/section-running-jobs-in-a-container-env.md Normal file
View File

@@ -0,0 +1 @@
Use `jobs.<job_id>.container.env` to set a `map` of environment variables in the container.

1
data/reusables/actions/jobs/section-running-jobs-in-a-container-image.md Normal file
View File

@@ -0,0 +1 @@
Use `jobs.<job_id>.container.image` to define the Docker image to use as the container to run the action. The value can be the Docker Hub image name or a registry name.

7
data/reusables/actions/jobs/section-running-jobs-in-a-container-options.md Normal file
View File

@@ -0,0 +1,7 @@
Use `jobs.<job_id>.container.options` to configure additional Docker container resource options. For a list of options, see "[`docker create` options](https://docs.docker.com/engine/reference/commandline/create/#options)."
{% warning %}
**Warning:** The `--network` option is not supported.
{% endwarning %}

1
data/reusables/actions/jobs/section-running-jobs-in-a-container-ports.md Normal file
View File

@@ -0,0 +1 @@
Use `jobs.<job_id>.container.ports` to set an `array` of ports to expose on the container.

16
data/reusables/actions/jobs/section-running-jobs-in-a-container-volumes.md Normal file
View File

@@ -0,0 +1,16 @@
Use `jobs.<job_id>.container.volumes` to set an `array` of volumes for the container to use. You can use volumes to share data between services or other steps in a job. You can specify named Docker volumes, anonymous Docker volumes, or bind mounts on the host.
To specify a volume, you specify the source and destination path:
`<source>:<destinationPath>`.
The `<source>` is a volume name or an absolute path on the host machine, and `<destinationPath>` is an absolute path in the container.
#### Example: Mounting volumes in a container
```yaml
volumes:
- my_docker_volume:/volume_mount
- /data/my_data
- /source/directory:/destination/directory
```

27
data/reusables/actions/jobs/section-running-jobs-in-a-container.md Normal file
View File

@@ -0,0 +1,27 @@
Use `jobs.<job_id>.container` to create a container to run any steps in a job that don't already specify a container. If you have steps that use both script and container actions, the container actions will run as sibling containers on the same network with the same volume mounts.
If you do not set a `container`, all steps will run directly on the host specified by `runs-on` unless a step refers to an action configured to run in a container.
### Example: Running a job within a container
```yaml
jobs:
my_job:
container:
image: node:14.16
env:
NODE_ENV: development
ports:
- 80
volumes:
- my_docker_volume:/volume_mount
options: --cpus 1
```
When you only specify a container image, you can omit the `image` keyword.
```yaml
jobs:
my_job:
container: node:14.16
```

1
data/reusables/actions/jobs/section-using-a-build-matrix-for-your-jobs-failfast.md Normal file
View File

@@ -0,0 +1 @@
When `jobs.<job_id>.strategy.fail-fast` is set to `true`, {% data variables.product.prodname_dotcom %} cancels all in-progress jobs if any `matrix` job fails. Default: `true`

126
data/reusables/actions/jobs/section-using-a-build-matrix-for-your-jobs-matrix.md Normal file
View File

@@ -0,0 +1,126 @@
Use `jobs.<job_id>.strategy.matrix` to define a matrix of different job configurations. A matrix allows you to create multiple jobs by performing variable substitution in a single job definition. For example, you can use a matrix to create jobs for more than one supported version of a programming language, operating system, or tool. A matrix reuses the job's configuration and creates a job for each matrix you configure.
{% data reusables.github-actions.usage-matrix-limits %}
Each option you define in the `matrix` has a key and value. The keys you define become properties in the `matrix` context and you can reference the property in other areas of your workflow file. For example, if you define the key `os` that contains an array of operating systems, you can use the `matrix.os` property as the value of the `runs-on` keyword to create a job for each operating system. For more information, see "[Contexts](/actions/learn-github-actions/contexts)."
The order that you define a `matrix` matters. The first option you define will be the first job that runs in your workflow.
#### Example: Running multiple versions of Node.js
You can specify a matrix by supplying an array for the configuration options. For example, if the runner supports Node.js versions 10, 12, and 14, you could specify an array of those versions in the `matrix`.
This example creates a matrix of three jobs by setting the `node` key to an array of three Node.js versions. To use the matrix, the example sets the `matrix.node` context property as the value of the `setup-node` action's input parameter `node-version`. As a result, three jobs will run, each using a different Node.js version.
{% raw %}
```yaml
strategy:
matrix:
node: [10, 12, 14]
steps:
# Configures the node version used on GitHub-hosted runners
- uses: actions/setup-node@v2
with:
# The Node.js version to configure
node-version: ${{ matrix.node }}
```
{% endraw %}
The `setup-node` action is the recommended way to configure a Node.js version when using {% data variables.product.prodname_dotcom %}-hosted runners. For more information, see the [`setup-node`](https://github.com/actions/setup-node) action.
#### Example: Running with multiple operating systems
You can create a matrix to run workflows on more than one runner operating system. You can also specify more than one matrix configuration. This example creates a matrix of 6 jobs:
- 2 operating systems specified in the `os` array
- 3 Node.js versions specified in the `node` array
{% data reusables.repositories.actions-matrix-builds-os %}
{% raw %}
```yaml
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-18.04, ubuntu-20.04]
node: [10, 12, 14]
steps:
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node }}
```
{% endraw %}
{% ifversion ghae %}
For more information about the configuration of self-hosted runners, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners)."
{% else %}To find supported configuration options for {% data variables.product.prodname_dotcom %}-hosted runners, see "[Virtual environments for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners)."
{% endif %}
#### Example: Including additional values in combinations
You can add additional configuration options to a build matrix job that already exists. For example, if you want to use a specific version of `npm` when the job that uses `windows-latest` and version 8 of `node` runs, you can use `include` to specify that additional option.
{% raw %}
```yaml
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [macos-latest, windows-latest, ubuntu-18.04]
node: [8, 10, 12, 14]
include:
# includes a new variable of npm with a value of 6
# for the matrix leg matching the os and version
- os: windows-latest
node: 8
npm: 6
```
{% endraw %}
#### Example: Including new combinations
You can use `include` to add new jobs to a build matrix. Any unmatched include configurations are added to the matrix. For example, if you want to use `node` version 14 to build on multiple operating systems, but wanted one extra experimental job using node version 15 on Ubuntu, you can use `include` to specify that additional job.
{% raw %}
```yaml
runs-on: ${{ matrix.os }}
strategy:
matrix:
node: [14]
os: [macos-latest, windows-latest, ubuntu-18.04]
include:
- node: 15
os: ubuntu-18.04
experimental: true
```
{% endraw %}
#### Example: Excluding configurations from a matrix
You can remove a specific configurations defined in the build matrix using the `exclude` option. Using `exclude` removes a job defined by the build matrix. The number of jobs is the cross product of the number of operating systems (`os`) included in the arrays you provide, minus any subtractions (`exclude`).
{% raw %}
```yaml
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [macos-latest, windows-latest, ubuntu-18.04]
node: [8, 10, 12, 14]
exclude:
# excludes node 8 on macOS
- os: macos-latest
node: 8
```
{% endraw %}
{% note %}
**Note:** All `include` combinations are processed after `exclude`. This allows you to use `include` to add back combinations that were previously excluded.
{% endnote %}
### Using environment variables in a matrix
You can add custom environment variables for each test combination by using the `include` key. You can then refer to the custom environment variables in a later step.
{% data reusables.github-actions.matrix-variable-example %}

6
data/reusables/actions/jobs/section-using-a-build-matrix-for-your-jobs-max-parallel.md Normal file
View File

@@ -0,0 +1,6 @@
Use `jobs.<job_id>.strategy.max-parallel` to set the maximum number of jobs that can run simultaneously when using a `matrix` job strategy. By default, {% data variables.product.prodname_dotcom %} will maximize the number of jobs run in parallel depending on the available runners on {% data variables.product.prodname_dotcom %}-hosted virtual machines.
```yaml
strategy:
max-parallel: 2
```

1
data/reusables/actions/jobs/section-using-a-build-matrix-for-your-jobs-strategy.md Normal file
View File

@@ -0,0 +1 @@
Use `jobs.<job_id>.strategy` to create a build matrix for your jobs. You can define different variations to run each job in.

11
data/reusables/actions/jobs/section-using-concurrency-jobs.md Normal file
View File

@@ -0,0 +1,11 @@
{% note %}
**Note:** When concurrency is specified at the job level, order is not guaranteed for jobs or runs that queue within 5 minutes of each other.
{% endnote %}
You can use `jobs.<job_id>.concurrency` to ensure that only a single job or workflow using the same concurrency group will run at a time. A concurrency group can be any string or expression. The expression can use any context except for the `secrets` context. For more information about expressions, see "[Expressions](/actions/learn-github-actions/expressions)."
You can also specify `concurrency` at the workflow level. For more information, see [`concurrency`](/actions/using-workflows/workflow-syntax-for-github-actions#concurrency).
{% data reusables.actions.actions-group-concurrency %}

5
data/reusables/actions/jobs/section-using-concurrency.md Normal file
View File

@@ -0,0 +1,5 @@
Use `concurrency` to ensure that only a single job or workflow using the same concurrency group will run at a time. A concurrency group can be any string or expression. A concurrency group can be any string or expression. The expression can only use the [`github` context](/actions/learn-github-actions/contexts#github-context). For more information about expressions, see "[Expressions](/actions/learn-github-actions/expressions)."
You can also specify `concurrency` at the job level. For more information, see [`jobs.<job_id>.concurrency`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idconcurrency).
{% data reusables.actions.actions-group-concurrency %}

22
data/reusables/actions/jobs/section-using-conditions-to-control-job-execution.md Normal file
View File

@@ -0,0 +1,22 @@
You can use the `jobs.<job_id>.if` conditional to prevent a job from running unless a condition is met. You can use any supported context and expression to create a conditional.
{% data reusables.github-actions.expression-syntax-if %} For more information, see "[Expressions](/actions/learn-github-actions/expressions)."
### Example: Only run job for specific repository
This example uses `if` to control when the `production-deploy` job can run. It will only run if the repository is named `octo-repo-prod` and is within the `octo-org` organization. Otherwise, the job will be marked as _skipped_.
```yaml{:copy}
name: example-workflow
on: [push]
jobs:
production-deploy:
if: github.repository == 'octo-org/octo-repo-prod'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
with:
node-version: '14'
- run: npm install -g bats
```

29
data/reusables/actions/jobs/section-using-environments-for-jobs.md Normal file
View File

@@ -0,0 +1,29 @@
Use `jobs.<job_id>.environment` to define the environment that the job references. All environment protection rules must pass before a job referencing the environment is sent to a runner. For more information, see "[Using environments for deployment](/actions/deployment/using-environments-for-deployment)."
You can provide the environment as only the environment `name`, or as an environment object with the `name` and `url`. The URL maps to `environment_url` in the deployments API. For more information about the deployments API, see "[Deployments](/rest/reference/repos#deployments)."
### Example: Using a single environment name
{% raw %}
```yaml
environment: staging_environment
```
{% endraw %}
### Example: Using environment name and URL
```yaml
environment:
name: production_environment
url: https://github.com
```
The URL can be an expression and can use any context except for the [`secrets` context](/actions/learn-github-actions/contexts#contexts). For more information about expressions, see "[Expressions](/actions/learn-github-actions/expressions)."
### Example: Using output as URL
{% raw %}
```yaml
environment:
name: production_environment
url: ${{ steps.step_id.outputs.url_output }}
```
{% endraw %}

13
data/reusables/actions/jobs/section-using-jobs-in-a-workflow-id.md Normal file
View File

@@ -0,0 +1,13 @@
Use `jobs.<job_id>` to give your job a unique identifier. The key `job_id` is a string and its value is a map of the job's configuration data. You must replace `<job_id>` with a string that is unique to the `jobs` object. The `<job_id>` must start with a letter or `_` and contain only alphanumeric characters, `-`, or `_`.
#### Example: Creating jobs
In this example, two jobs have been created, and their `job_id` values are `my_first_job` and `my_second_job`.
```yaml
jobs:
my_first_job:
name: My first job
my_second_job:
name: My second job
```

1
data/reusables/actions/jobs/section-using-jobs-in-a-workflow-name.md Normal file
View File

@@ -0,0 +1 @@
Use `jobs.<job_id>.name` to a name for the job, which is displayed on {% data variables.product.prodname_dotcom %}.

34
data/reusables/actions/jobs/section-using-jobs-in-a-workflow-needs.md Normal file
View File

@@ -0,0 +1,34 @@
Use `jobs.<job_id>.needs` to identify any jobs that must complete successfully before this job will run. It can be a string or array of strings. If a job fails, all jobs that need it are skipped unless the jobs use a conditional expression that causes the job to continue.
#### Example: Requiring successful dependent jobs
```yaml
jobs:
job1:
job2:
needs: job1
job3:
needs: [job1, job2]
```
In this example, `job1` must complete successfully before `job2` begins, and `job3` waits for both `job1` and `job2` to complete.
The jobs in this example run sequentially:
1. `job1`
2. `job2`
3. `job3`
#### Example: Not requiring successful dependent jobs
```yaml
jobs:
job1:
job2:
needs: job1
job3:
if: {% raw %}${{ always() }}{% endraw %}
needs: [job1, job2]
```
In this example, `job3` uses the `always()` conditional expression so that it always runs after `job1` and `job2` have completed, regardless of whether they were successful. For more information, see "[Expressions](/actions/learn-github-actions/expressions#job-status-check-functions)."

7
data/reusables/actions/jobs/section-using-jobs-in-a-workflow.md Normal file
View File

@@ -0,0 +1,7 @@
A workflow run is made up of one or more `jobs`, which run in parallel by default. To run jobs sequentially, you can define dependencies on other jobs using the `jobs.<job_id>.needs` keyword.
Each job runs in a runner environment specified by `runs-on`.
You can run an unlimited number of jobs as long as you are within the workflow usage limits. For more information, see {% ifversion fpt or ghec or ghes %}"[Usage limits and billing](/actions/reference/usage-limits-billing-and-administration)" for {% data variables.product.prodname_dotcom %}-hosted runners and {% endif %}"[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners/#usage-limits){% ifversion fpt or ghec or ghes %}" for self-hosted runner usage limits.{% elsif ghae %}."{% endif %}
If you need to find the unique identifier of a job running in a workflow run, you can use the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API. For more information, see "[Workflow Jobs](/rest/reference/actions#workflow-jobs)."

17
data/reusables/actions/jobs/setting-default-values-for-jobs-defaults-job-run.md Normal file
View File

@@ -0,0 +1,17 @@
Use `jobs.<job_id>.defaults.run` to provide default `shell` and `working-directory` to all `run` steps in the job. Context and expression are not allowed in this section.
You can provide default `shell` and `working-directory` options for all [`run`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun) steps in a job. You can also set default settings for `run` for the entire workflow. For more information, see [`jobs.defaults.run`](/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrun). You cannot use contexts or expressions in this keyword.
{% data reusables.github-actions.defaults-override %}
#### Example: Setting default `run` step options for a job
```yaml
jobs:
job1:
runs-on: ubuntu-latest
defaults:
run:
shell: bash
working-directory: scripts
```

3
data/reusables/actions/jobs/setting-default-values-for-jobs-defaults-job.md Normal file
View File

@@ -0,0 +1,3 @@
Use `jobs.<job_id>.defaults` to create a `map` of default settings that will apply to all steps in the job. You can also set default settings for the entire workflow. For more information, see [`defaults`](/actions/using-workflows/workflow-syntax-for-github-actions#defaults).
{% data reusables.github-actions.defaults-override %}

12
data/reusables/actions/jobs/setting-default-values-for-jobs-defaults-run.md Normal file
View File

@@ -0,0 +1,12 @@
You can use `defaults.run` to provide default `shell` and `working-directory` options for all [`run`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun) steps in a workflow. You can also set default settings for `run` that are only available to a job. For more information, see [`jobs.<job_id>.defaults.run`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrun). You cannot use contexts or expressions in this keyword.
{% data reusables.github-actions.defaults-override %}
#### Example: Set the default shell and working directory
```yaml
defaults:
run:
shell: bash
working-directory: scripts
```

3
data/reusables/actions/jobs/setting-default-values-for-jobs-defaults.md Normal file
View File

@@ -0,0 +1,3 @@
Use `defaults` to create a `map` of default settings that will apply to all jobs in the workflow. You can also set default settings that are only available to a job. For more information, see [`jobs.<job_id>.defaults`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaults).
{% data reusables.github-actions.defaults-override %}

2
data/reusables/actions/registry-credentials.md
View File

@@ -1 +1 @@
If the image's container registry requires authentication to pull the image, you can use `credentials` to set a `map` of the `username` and `password`. The credentials are the same values that you would provide to the [`docker login`](https://docs.docker.com/engine/reference/commandline/login/) command.
If the image's container registry requires authentication to pull the image, you can use `jobs.<job_id>.container.credentials` to set a `map` of the `username` and `password`. The credentials are the same values that you would provide to the [`docker login`](https://docs.docker.com/engine/reference/commandline/login/) command.

77
data/reusables/actions/workflows/section-run-on-specific-branches-or-tags.md Normal file
View File

@@ -0,0 +1,77 @@
When using the `push` event, you can configure a workflow to run on specific branches or tags.
Use the `branches` filter when you want to include branch name patterns or when you want to both include and exclude branch names patterns. Use the `branches-ignore` filter when you only want to exclude branch name patterns. You cannot use both the `branches` and `branches-ignore` filters for the same event in a workflow.
Use the `tags` filter when you want to include tag name patterns or when you want to both include and exclude tag names patterns. Use the `tags-ignore` filter when you only want to exclude tag name patterns. You cannot use both the `tags` and `tags-ignore` filters for the same event in a workflow.
If you define only `tags`/`tag-ignore` or only `branches`/`branches-ignore`, the workflow won't run for events affecting the undefined Git ref. If you define neither `tags`/`tag-ignore` or `branches`/`branches-ignore`, the workflow will run for events affecting either branches or tags. If you define both `branches`/`branches-ignore` and [`paths`](#onpushpull_requestpull_request_targetpathspaths-ignore), the workflow will only run when both filters are satisfied.
The `branches`, `branches-ignore`, `tags`, and `tags-ignore` keywords accept glob patterns that use characters like `*`, `**`, `+`, `?`, `!` and others to match more than one branch or tag name. If a name contains any of these characters and you want a literal match, you need to *escape* each of these special characters with `\`. For more information about glob patterns, see the "[Filter pattern cheat sheet](#filter-pattern-cheat-sheet)."
#### Example: Including branches and tags
The patterns defined in `branches` and `tags` are evaluated against the Git ref's name. For example, the following workflow would run whenever there is a `push` event to:
- A branch named `main` (`refs/heads/main`)
- A branch named `mona/octocat` (`refs/heads/mona/octocat`)
- A branch whose name starts with `releases/`, like `releases/10` (`refs/heads/releases/10`)
- A tag named `v2` (`refs/tags/v2`)
- A tag whose name starts with `v1.`, like `v1.9.1` (`refs/tags/v1.9.1`)
```yaml
on:
push:
# Sequence of patterns matched against refs/heads
branches:
- main
- 'mona/octocat'
- 'releases/**'
# Sequence of patterns matched against refs/tags
tags:
- v2
- v1.*
```
#### Example: Excluding branches and tags
When a pattern matches the `branches-ignore` or `tags-ignore` pattern, the workflow will not run. The patterns defined in `branches` and `tags` are evaluated against the Git ref's name. For example, the following workflow would run whenever there is a `push` event, unless the `push` event is to:
- A branch named `mona/octocat` (`refs/heads/mona/octocat`)
- A branch whose name matches `releases/**-alpha`, like `beta/3-alpha` (`refs/releases/beta/3-alpha`)
- A tag named `v2` (`refs/tags/v2`)
- A tag whose name starts with `v1.`, like `v1.9` (`refs/tags/v1.9`)
```yaml
on:
push:
# Sequence of patterns matched against refs/heads
branches-ignore:
- 'mona/octocat'
- 'releases/**-alpha'
# Sequence of patterns matched against refs/tags
tags-ignore:
- v2
- v1.*
```
#### Example: Including and excluding branches and tags
You can't use `branches` and `branches-ignore` to filter the same event in a single workflow. Similarly, you can't use `tags` and `tags-ignore` to filter the same event in a single workflow. If you want to both include and exclude branch or tag patterns for a single event, use the `branches` or `tags` filter along with the `!` character to indicate which branches or tags should be excluded.
If you define a branch with the `!` character, you must also define at least one branch without the `!` character. If you only want to exclude branches, use `branches-ignore` instead. Similarly, if you define a tag with the `!` character, you must also define at least one tag without the `!` character. If you only want to exclude tags, use `tags-ignore` instead.
The order that you define patterns matters.
- A matching negative pattern (prefixed with `!`) after a positive match will exclude the Git ref.
- A matching positive pattern after a negative match will include the Git ref again.
The following workflow will run on pushes to `releases/10` or `releases/beta/mona`, but not on `releases/10-alpha` or `releases/beta/3-alpha` because the negative pattern `!releases/**-alpha` follows the positive pattern.
```yaml
on:
push:
branches:
- 'releases/**'
- '!releases/**-alpha'
```

45
data/reusables/actions/workflows/section-specifying-branches.md Normal file
View File

@@ -0,0 +1,45 @@
When using the `workflow_run` event, you can specify what branches the triggering workflow must run on in order to trigger your workflow.
The `branches` and `branches-ignore` filters accept glob patterns that use characters like `*`, `**`, `+`, `?`, `!` and others to match more than one branch name. If a name contains any of these characters and you want a literal match, you need to *escape* each of these special characters with `\`. For more information about glob patterns, see the "[Filter pattern cheat sheet](#filter-pattern-cheat-sheet)."
For example, a workflow with the following trigger will only run when the workflow named `Build` runs on a branch whose name starts with `releases/`:
```yaml
on:
workflow_run:
workflows: ["Build"]
types: [requested]
branches:
- 'releases/**'
```
A workflow with the following trigger will only run when the workflow named `Build` runs on a branch that is not named `canary`:
```yaml
on:
workflow_run:
workflows: ["Build"]
types: [requested]
branches-ignore:
- "canary"
```
You cannot use both the `branches` and `branches-ignore` filters for the same event in a workflow. If you want to both include and exclude branch patterns for a single event, use the `branches` filter along with the `!` character to indicate which branches should be excluded.
The order that you define patterns matters.
- A matching negative pattern (prefixed with `!`) after a positive match will exclude the branch.
- A matching positive pattern after a negative match will include the branch again.
For example, a workflow with the following trigger will run when the workflow named `Build` runs on a branch that is named `releases/10` or `releases/beta/mona` but will not `releases/10-alpha`, `releases/beta/3-alpha`, or `main`.
```yaml
on:
workflow_run:
workflows: ["Build"]
types: [requested]
branches:
- 'releases/**'
- '!releases/**-alpha'
```

62
data/reusables/actions/workflows/section-triggering-a-workflow-branches.md Normal file
View File

@@ -0,0 +1,62 @@
When using the `pull_request` and `pull_request_target` events, you can configure a workflow to run only for pull requests that target specific branches.
Use the `branches` filter when you want to include branch name patterns or when you want to both include and exclude branch names patterns. Use the `branches-ignore` filter when you only want to exclude branch name patterns. You cannot use both the `branches` and `branches-ignore` filters for the same event in a workflow.
If you define both `branches`/`branches-ignore` and [`paths`](#onpushpull_requestpull_request_targetpathspaths-ignore), the workflow will only run when both filters are satisfied.
The `branches` and `branches-ignore` keywords accept glob patterns that use characters like `*`, `**`, `+`, `?`, `!` and others to match more than one branch name. If a name contains any of these characters and you want a literal match, you need to escape each of these special characters with `\`. For more information about glob patterns, see the "[Filter pattern cheat sheet](#filter-pattern-cheat-sheet)."
#### Example: Including branches
The patterns defined in `branches` are evaluated against the Git ref's name. For example, the following workflow would run whenever there is a `pull_request` event for a pull request targeting:
- A branch named `main` (`refs/heads/main`)
- A branch named `mona/octocat` (`refs/heads/mona/octocat`)
- A branch whose name starts with `releases/`, like `releases/10` (`refs/heads/releases/10`)
```yaml
on:
pull_request:
# Sequence of patterns matched against refs/heads
branches:
- main
- 'mona/octocat'
- 'releases/**'
```
#### Example: Excluding branches
When a pattern matches the `branches-ignore` pattern, the workflow will not run. The patterns defined in `branches` are evaluated against the Git ref's name. For example, the following workflow would run whenever there is a `pull_request` event unless the pull request is targeting:
- A branch named `mona/octocat` (`refs/heads/mona/octocat`)
- A branch whose name matches `releases/**-alpha`, like `beta/3-alpha` (`refs/releases/beta/3-alpha`)
```yaml
on:
pull_request:
# Sequence of patterns matched against refs/heads
branches-ignore:
- 'mona/octocat'
- 'releases/**-alpha'
```
#### Example: Including and excluding branches
You cannot use `branches` and `branches-ignore` to filter the same event in a single workflow. If you want to both include and exclude branch patterns for a single event, use the `branches` filter along with the `!` character to indicate which branches should be excluded.
If you define a branch with the `!` character, you must also define at least one branch without the `!` character. If you only want to exclude branches, use `branches-ignore` instead.
The order that you define patterns matters.
- A matching negative pattern (prefixed with `!`) after a positive match will exclude the Git ref.
- A matching positive pattern after a negative match will include the Git ref again.
The following workflow will run on `pull_request` events for pull requests that target `releases/10` or `releases/beta/mona`, but for pull requests that target `releases/10-alpha` or `releases/beta/3-alpha` because the negative pattern `!releases/**-alpha` follows the positive pattern.
```yaml
on:
pull_request:
branches:
- 'releases/**'
- '!releases/**-alpha'
```

72
data/reusables/actions/workflows/section-triggering-a-workflow-paths.md Normal file
View File

@@ -0,0 +1,72 @@
When using the `push` and `pull_request` events, you can configure a workflow to run based on what file paths are changed. Path filters are not evaluated for pushes of tags.
Use the `paths` filter when you want to include file path patterns or when you want to both include and exclude file path patterns. Use the `paths-ignore` filter when you only want to exclude file path patterns. You cannot use both the `paths` and `paths-ignore` filters for the same event in a workflow.
If you define both `branches`/`branches-ignore` and `paths`, the workflow will only run when both filters are satisfied.
The `paths` and `paths-ignore` keywords accept glob patterns that use the `*` and `**` wildcard characters to match more than one path name. For more information, see the "[Filter pattern cheat sheet](#filter-pattern-cheat-sheet)."
#### Example: Including paths
If at least one path matches a pattern in the `paths` filter, the workflow runs. For example, the following workflow would run anytime you push a JavaScript file (`.js`).
```yaml
on:
push:
paths:
- '**.js'
```
#### Example: Excluding paths
When all the path names match patterns in `paths-ignore`, the workflow will not run. If any path names do not match patterns in `paths-ignore`, even if some path names match the patterns, the workflow will run.
A workflow with the following path filter will only run on `push` events that include at least one file outside the `docs` directory at the root of the repository.
```yaml
on:
push:
paths-ignore:
- 'docs/**'
```
#### Example: Including and excluding paths
You can not use `paths` and `paths-ignore` to filter the same event in a single workflow. If you want to both include and exclude path patterns for a single event, use the `paths` filter along with the `!` character to indicate which paths should be excluded.
If you define a path with the `!` character, you must also define at least one path without the `!` character. If you only want to exclude paths, use `paths-ignore` instead.
The order that you define patterns matters:
- A matching negative pattern (prefixed with `!`) after a positive match will exclude the path.
- A matching positive pattern after a negative match will include the path again.
This example runs anytime the `push` event includes a file in the `sub-project` directory or its subdirectories, unless the file is in the `sub-project/docs` directory. For example, a push that changed `sub-project/index.js` or `sub-project/src/index.js` will trigger a workflow run, but a push changing only `sub-project/docs/readme.md` will not.
```yaml
on:
push:
paths:
- 'sub-project/**'
- '!sub-project/docs/**'
```
### Git diff comparisons
{% note %}
**Note:** If you push more than 1,000 commits, or if {% data variables.product.prodname_dotcom %} does not generate the diff due to a timeout, the workflow will always run.
{% endnote %}
The filter determines if a workflow should run by evaluating the changed files and running them against the `paths-ignore` or `paths` list. If there are no files changed, the workflow will not run.
{% data variables.product.prodname_dotcom %} generates the list of changed files using two-dot diffs for pushes and three-dot diffs for pull requests:
- **Pull requests:** Three-dot diffs are a comparison between the most recent version of the topic branch and the commit where the topic branch was last synced with the base branch.
- **Pushes to existing branches:** A two-dot diff compares the head and base SHAs directly with each other.
- **Pushes to new branches:** A two-dot diff against the parent of the ancestor of the deepest commit pushed.
Diffs are limited to 300 files. If there are files changed that aren't matched in the first 300 files returned by the filter, the workflow will not run. You may need to create more specific filters so that the workflow will run automatically.
For more information, see "[About comparing branches in pull requests](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests)."

3
data/reusables/actions/workflows/section-triggering-a-workflow-schedule.md Normal file
View File

@@ -0,0 +1,3 @@
You can use `on.schedule` to define a time schedule for your workflows. {% data reusables.repositories.actions-scheduled-workflow-example %}
For more information about cron syntax, see "[Events that trigger workflows](/actions/automating-your-workflow-with-github-actions/events-that-trigger-workflows#scheduled-events)."

9
data/reusables/actions/workflows/section-triggering-a-workflow-types.md Normal file
View File

@@ -0,0 +1,9 @@
Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the `label` is triggered when a label is `created`, `edited`, or `deleted`. The `types` keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the `types` keyword is unnecessary.
You can use an array of event `types`. For more information about each event and their activity types, see "[Events that trigger workflows](/articles/events-that-trigger-workflows#webhook-events)."
```yaml
on:
label:
types: [created, edited]
```

6
data/reusables/actions/workflows/section-triggering-a-workflow.md Normal file
View File

@@ -0,0 +1,6 @@
To automatically trigger a workflow, use `on` to define which events can cause the workflow to run. For a list of available events, see "[Events that trigger workflows](/articles/events-that-trigger-workflows)."
You can define single or multiple events that can a trigger workflow, or set a time schedule. You can also restrict the execution of a workflow to only occur for specific files, tags, or branch changes. These options are described in the following sections.
{% data reusables.github-actions.actions-on-examples %}

2
data/reusables/github-actions/actions-on-examples.md
View File

@@ -6,7 +6,7 @@ For example, a workflow with the following `on` value will run when a push is ma
on: push
```
### Using a multiple events
### Using multiple events
You can specify a single event or multiple events. For example, a workflow with the following `on` value will run when a push is made to any branch in the repository or when someone forks the repository:

99
translations/es-ES/content/actions/learn-github-actions/creating-starter-workflows-for-your-organization.md
View File

@@ -1,99 +0,0 @@
---
title: Creating starter workflows for your organization
shortTitle: Creating starter workflows
intro: Learn how you can create starter workflows to help people in your team add new workflows more easily.
redirect_from:
- /actions/configuring-and-managing-workflows/sharing-workflow-templates-within-your-organization
- /actions/learn-github-actions/creating-workflow-templates
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- Workflows
- CI
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Resumen
{% data reusables.actions.workflow-organization-templates %}
## Creating a starter workflow
Starter workflows can be created by users with write access to the organization's `.github` repository. These can then be used by organization members who have permission to create workflows.
{% ifversion fpt %}
Starter workflows created by users can only be used to create workflows in public repositories. Organizations using {% data variables.product.prodname_ghe_cloud %} can also use starter workflows to create workflows in private repositories. Para obtener más información, consulta la [documentación de {% data variables.product.prodname_ghe_cloud %}](/enterprise-cloud@latest/actions/learn-github-actions/creating-starter-workflows-for-your-organization).
{% endif %}
{% ifversion fpt or ghes > 3.3 or ghae-issue-4757 or ghec %}
{% note %}
**Note:** To avoid duplication among starter workflows you can call reusable workflows from within a workflow. Esto puede ayudar a que tus flujos de trabajo se mantengan más fácilmente. Para obtener más información, consulta la sección "[Reutilizar flujos de trabajo](/actions/learn-github-actions/reusing-workflows)".
{% endnote %}
{% endif %}
This procedure demonstrates how to create a starter workflow and metadata file. The metadata file describes how the starter workflows will be presented to users when they are creating a new workflow.
1. En caso de que no exista previamente, crea en tu organización un repositorio público nuevo que se llame `.github`.
2. Crea un directorio que se llame `workflow-templates`.
3. Crea tu nuevo archivo de flujo de trabajo dentro del directorio `workflow-templates`.
Si necesitas referirte a la rama predeterminada de un repositorio, puedes utilizar el marcador de posición `$default-branch`. When a workflow is created the placeholder will be automatically replaced with the name of the repository's default branch.
Por ejemplo, este archivo de nombre `octo-organization-ci.yml` ilustra un flujo de trabajo básico.
```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@v2
- name: Run a one-line script
run: echo Hello from Octo Organization
```
4. Crea un archivo de metadatos dentro del directorio `workflow-templates`. El archivo de metadatos debe tener el mismo nombre que el archivo de flujo de trabajo, pero en vez de tener la extensión `.yml`, este deberá encontrarse adjunto en `.properties.json`. Por ejemplo, este archivo que se llama `octo-organization-ci.properties.json` contiene los metadatos para un archivo de flujo de trabajo de nombre `octo-organization-ci.yml`:
```yaml
{
"name": "Octo Organization Workflow",
"description": "Octo Organization CI starter workflow.",
"iconName": "example-icon",
"categories": [
"Go"
],
"filePatterns": [
"package.json$",
"^Dockerfile",
".*\\.md$"
]
}
```
* `name` - **Required.** The name of the workflow. This is displayed in the list of available workflows.
* `description` - **Required.** The description of the workflow. This is displayed in the list of available workflows.
* `iconName` - **Optional.** Specifies an icon for the workflow that's displayed in the list of workflows. The `iconName` must be the name of an SVG file, without the file name extension, stored in the `workflow-templates` directory. For example, an SVG file named `example-icon.svg` is referenced as `example-icon`.
* `categories` - **Opcional.** Define la categoría de lenguaje del flujo de trabajo. When a user views the available starter workflows for a repository, the workflows that match the identified language for the project are featured more prominently. Para obtener información sobre las categorías de lenguaje disponibles, consulta https://github.com/github/linguist/blob/master/lib/linguist/languages.yml.
* `filePatterns` - **Optional.** Allows the workflow to be used if the user's repository has a file in its root directory that matches a defined regular expression.
To add another starter workflow, add your files to the same `workflow-templates` directory. Por ejemplo:
![Workflow files](/assets/images/help/images/workflow-template-files.png)
## Pasos siguientes
To continue learning about {% data variables.product.prodname_actions %}, see "[Using starter workflows](/actions/learn-github-actions/using-starter-workflows)."

865
translations/es-ES/content/actions/learn-github-actions/events-that-trigger-workflows.md
View File

@@ -1,865 +0,0 @@
---
title: Events that trigger workflows
intro: 'You can configure your workflows to run when specific activity on {% data variables.product.product_name %} happens, at a scheduled time, or when an event outside of {% data variables.product.product_name %} occurs.'
miniTocMaxHeadingLevel: 3
redirect_from:
- /articles/events-that-trigger-workflows
- /github/automating-your-workflow-with-github-actions/events-that-trigger-workflows
- /actions/automating-your-workflow-with-github-actions/events-that-trigger-workflows
- /actions/reference/events-that-trigger-workflows
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
shortTitle: Events that trigger workflows
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Configuring workflow events
You can configure workflows to run for one or more events using the `on` workflow syntax. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions#on)."
{% data reusables.github-actions.actions-on-examples %}
{% note %}
**Note:** You cannot trigger new workflow runs using the `GITHUB_TOKEN`. For more information, see "[Triggering new workflows using a personal access token](#triggering-new-workflows-using-a-personal-access-token)."
{% endnote %}
The following steps occur to trigger a workflow run:
1. An event occurs on your repository, and the resulting event has an associated commit SHA and Git ref.
2. The `.github/workflows` directory in your repository is searched for workflow files at the associated commit SHA or Git ref. The workflow files must be present in that commit SHA or Git ref to be considered.
For example, if the event occurred on a particular repository branch, then the workflow files must be present in the repository on that branch.
1. The workflow files for that commit SHA and Git ref are inspected, and a new workflow run is triggered for any workflows that have `on:` values that match the triggering event.
The workflow runs on your repository's code at the same commit SHA and Git ref that triggered the event. When a workflow runs, {% data variables.product.product_name %} sets the `GITHUB_SHA` (commit SHA) and `GITHUB_REF` (Git ref) environment variables in the runner environment. For more information, see "[Using environment variables](/actions/automating-your-workflow-with-github-actions/using-environment-variables)."
## Scheduled events
The `schedule` event allows you to trigger a workflow at a scheduled time.
{% data reusables.actions.schedule-delay %}
### `schedule`
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| n/a | n/a | Last commit on default branch | Default branch | When the scheduled workflow is set to run. A scheduled workflow uses [POSIX cron syntax](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07). For more information, see "[Triggering a workflow with events](/articles/configuring-a-workflow/#triggering-a-workflow-with-events)." |
{% data reusables.repositories.actions-scheduled-workflow-example %}
Cron syntax has five fields separated by a space, and each field represents a unit of time.
```
┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
* * * * *
```
You can use these operators in any of the five fields:
| Operator | Description | Example |
| -------- | ----------- | ------- |
| * | Any value | `* * * * *` runs every minute of every day. |
| , | Value list separator | `2,10 4,5 * * *` runs at minute 2 and 10 of the 4th and 5th hour of every day. |
| - | Range of values | `0 4-6 * * *` runs at minute 0 of the 4th, 5th, and 6th hour. |
| / | Step values | `20/15 * * * *` runs every 15 minutes starting from minute 20 through 59 (minutes 20, 35, and 50). |
{% note %}
**Note:** {% data variables.product.prodname_actions %} does not support the non-standard syntax `@yearly`, `@monthly`, `@weekly`, `@daily`, `@hourly`, and `@reboot`.
{% endnote %}
You can use [crontab guru](https://crontab.guru/) to help generate your cron syntax and confirm what time it will run. To help you get started, there is also a list of [crontab guru examples](https://crontab.guru/examples.html).
Notifications for scheduled workflows are sent to the user who last modified the cron syntax in the workflow file. For more information, please see "[Notifications for workflow runs](/actions/guides/about-continuous-integration#notifications-for-workflow-runs)."
## Manual events
You can manually trigger workflow runs. To trigger specific workflows in a repository, use the `workflow_dispatch` event. To trigger more than one workflow in a repository and create custom events and event types, use the `repository_dispatch` event.
### `workflow_dispatch`
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------ | ------------ | ------------ | ------------------|
| [workflow_dispatch](/webhooks/event-payloads/#workflow_dispatch) | n/a | Last commit on the `GITHUB_REF` branch | Branch that received dispatch |
You can configure custom-defined input properties, default input values, and required inputs for the event directly in your workflow. When the workflow runs, you can access the input values in the `github.event.inputs` context. For more information, see "[Contexts](/actions/learn-github-actions/contexts)."
You can manually trigger a workflow run using the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API and from {% data variables.product.product_name %}. For more information, see "[Manually running a workflow](/actions/managing-workflow-runs/manually-running-a-workflow)."
When you trigger the event on {% data variables.product.prodname_dotcom %}, you can provide the `ref` and any `inputs` directly on {% data variables.product.prodname_dotcom %}. For more information, see "[Using inputs and outputs with an action](/actions/learn-github-actions/finding-and-customizing-actions#using-inputs-and-outputs-with-an-action)."
To trigger the custom `workflow_dispatch` webhook event using the REST API, you must send a `POST` request to a {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API endpoint and provide the `ref` and any required `inputs`. For more information, see the "[Create a workflow dispatch event](/rest/reference/actions/#create-a-workflow-dispatch-event)" REST API endpoint.
#### Example
To use the `workflow_dispatch` event, you need to include it as a trigger in your GitHub Actions workflow file. The example below only runs the workflow when it's manually triggered:
```yaml
on: workflow_dispatch
```
#### Example workflow configuration
This example defines the `name` and `home` inputs and prints them using the `github.event.inputs.name` and `github.event.inputs.home` contexts. If a `home` isn't provided, the default value 'The Octoverse' is printed.
{% raw %}
```yaml
name: Manually triggered workflow
on:
workflow_dispatch:
inputs:
name:
description: 'Person to greet'
required: true
default: 'Mona the Octocat'
home:
description: 'location'
required: false
default: 'The Octoverse'
jobs:
say_hello:
runs-on: ubuntu-latest
steps:
- run: |
echo "Hello ${{ github.event.inputs.name }}!"
echo "- in ${{ github.event.inputs.home }}!"
```
{% endraw %}
### `repository_dispatch`
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------ | ------------ | ------------ | ------------------|
| [repository_dispatch](/webhooks/event-payloads/#repository_dispatch) | n/a | Last commit on default branch | Default branch |
{% data reusables.github-actions.branch-requirement %}
You can use the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API to trigger a webhook event called [`repository_dispatch`](/webhooks/event-payloads/#repository_dispatch) when you want to trigger a workflow for activity that happens outside of {% data variables.product.prodname_dotcom %}. For more information, see "[Create a repository dispatch event](/rest/reference/repos#create-a-repository-dispatch-event)."
To trigger the custom `repository_dispatch` webhook event, you must send a `POST` request to a {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API endpoint and provide an `event_type` name to describe the activity type. To trigger a workflow run, you must also configure your workflow to use the `repository_dispatch` event.
#### Example
By default, all `event_types` trigger a workflow to run. You can limit your workflow to run when a specific `event_type` value is sent in the `repository_dispatch` webhook payload. You define the event types sent in the `repository_dispatch` payload when you create the repository dispatch event.
```yaml
on:
repository_dispatch:
types: [opened, deleted]
```
{% ifversion fpt or ghes > 3.3 or ghae-issue-4757 or ghec %}
## Workflow reuse events
`workflow_call` is a keyword used as the value of `on` in a workflow, in the same way as an event. It indicates that a workflow can be called from another workflow. For more information see, "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)."
### `workflow_call`
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------ | ------------ | ------------ | ------------------|
| Same as the caller workflow | n/a | Same as the caller workflow | Same as the caller workflow |
#### Example
To make a workflow reusable it must include `workflow_call` as one of the values of `on`. The example below only runs the workflow when it's called from another workflow:
```yaml
on: workflow_call
```
{% endif %}
## Webhook events
You can configure your workflow to run when webhook events are generated on {% data variables.product.product_name %}. Some events have more than one activity type that triggers the event. If more than one activity type triggers the event, you can specify which activity types will trigger the workflow to run. For more information, see "[Webhooks](/webhooks)."
Not all webhook events trigger workflows. For the complete list of available webhook events and their payloads, see "[Webhook events and payloads](/developers/webhooks-and-events/webhook-events-and-payloads)."
{% ifversion fpt or ghec or ghes > 3.3 or ghae-issue-4968 %}
### `branch_protection_rule`
Runs your workflow anytime the `branch_protection_rule` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the GraphQL API, see "[BranchProtectionRule]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql/reference/objects#branchprotectionrule)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`branch_protection_rule`](/webhooks/event-payloads/#branch_protection_rule) | - `created`<br/>- `edited`<br/>- `deleted` | Last commit on default branch | Default branch |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a branch protection rule has been `created` or `deleted`.
```yaml
on:
branch_protection_rule:
types: [created, deleted]
```
{% endif %}
### `check_run`
Runs your workflow anytime the `check_run` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Check runs](/rest/reference/checks#runs)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`check_run`](/webhooks/event-payloads/#check_run) | - `created`<br/>- `rerequested`<br/>- `completed` | Last commit on default branch | Default branch |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a check run has been `rerequested` or `completed`.
```yaml
on:
check_run:
types: [rerequested, completed]
```
### `check_suite`
Runs your workflow anytime the `check_suite` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Check suites](/rest/reference/checks#suites)."
{% data reusables.github-actions.branch-requirement %}
{% note %}
**Note:** To prevent recursive workflows, this event does not trigger workflows if the check suite was created by {% data variables.product.prodname_actions %}.
{% endnote %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`check_suite`](/webhooks/event-payloads/#check_suite) | - `completed`<br/>- `requested`<br/>- `rerequested`<br/> | Last commit on default branch | Default branch |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a check suite has been `rerequested` or `completed`.
```yaml
on:
check_suite:
types: [rerequested, completed]
```
### `create`
Runs your workflow anytime someone creates a branch or tag, which triggers the `create` event. For information about the REST API, see "[Create a reference](/rest/reference/git#create-a-reference)."
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`create`](/webhooks/event-payloads/#create) | n/a | Last commit on the created branch or tag | Branch or tag created |
For example, you can run a workflow when the `create` event occurs.
```yaml
on:
create
```
### `delete`
Runs your workflow anytime someone deletes a branch or tag, which triggers the `delete` event. For information about the REST API, see "[Delete a reference](/rest/reference/git#delete-a-reference)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`delete`](/webhooks/event-payloads/#delete) | n/a | Last commit on default branch | Default branch |
For example, you can run a workflow when the `delete` event occurs.
```yaml
on:
delete
```
### `deployment`
Runs your workflow anytime someone creates a deployment, which triggers the `deployment` event. Deployments created with a commit SHA may not have a Git ref. For information about the REST API, see "[Deployments](/rest/reference/repos#deployments)."
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`deployment`](/webhooks/event-payloads/#deployment) | n/a | Commit to be deployed | Branch or tag to be deployed (empty if commit)|
For example, you can run a workflow when the `deployment` event occurs.
```yaml
on:
deployment
```
### `deployment_status`
Runs your workflow anytime a third party provides a deployment status, which triggers the `deployment_status` event. Deployments created with a commit SHA may not have a Git ref. For information about the REST API, see "[Create a deployment status](/rest/reference/deployments#create-a-deployment-status)."
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`deployment_status`](/webhooks/event-payloads/#deployment_status) | n/a | Commit to be deployed | Branch or tag to be deployed (empty if commit)|
For example, you can run a workflow when the `deployment_status` event occurs.
```yaml
on:
deployment_status
```
{% note %}
**Note:** When a deployment status's state is set to `inactive`, a webhook event will not be created.
{% endnote %}
{% ifversion fpt or ghec %}
### `discussion`
Runs your workflow anytime the `discussion` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the GraphQL API, see "[Discussions]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql/guides/using-the-graphql-api-for-discussions)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`discussion`](/webhooks/event-payloads/#discussion) | - `created`<br/>- `edited`<br/>- `deleted`<br/>- `transferred`<br/>- `pinned`<br/>- `unpinned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `locked`<br/>- `unlocked`<br/>- `category_changed`<br/> - `answered`<br/> - `unanswered` | Last commit on default branch | Default branch |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a discussion has been `created`, `edited`, or `answered`.
```yaml
on:
discussion:
types: [created, edited, answered]
```
### `discussion_comment`
Runs your workflow anytime the `discussion_comment` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the GraphQL API, see "[Discussions]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql/guides/using-the-graphql-api-for-discussions)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`discussion_comment`](/developers/webhooks-and-events/webhook-events-and-payloads#discussion_comment) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | Last commit on default branch | Default branch |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when an issue comment has been `created` or `deleted`.
```yaml
on:
discussion_comment:
types: [created, deleted]
```
{% endif %}
### `fork`
Runs your workflow anytime when someone forks a repository, which triggers the `fork` event. For information about the REST API, see "[Create a fork](/rest/reference/repos#create-a-fork)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`fork`](/webhooks/event-payloads/#fork) | n/a | Last commit on default branch | Default branch |
For example, you can run a workflow when the `fork` event occurs.
```yaml
on:
fork
```
### `gollum`
Runs your workflow when someone creates or updates a Wiki page, which triggers the `gollum` event.
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`gollum`](/webhooks/event-payloads/#gollum) | n/a | Last commit on default branch | Default branch |
For example, you can run a workflow when the `gollum` event occurs.
```yaml
on:
gollum
```
### `issue_comment`
Runs your workflow anytime the `issue_comment` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Issue comments](/developers/webhooks-and-events/webhook-events-and-payloads#issue_comment)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`issue_comment`](/developers/webhooks-and-events/webhook-events-and-payloads#issue_comment) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | Last commit on default branch | Default branch |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when an issue comment has been `created` or `deleted`.
```yaml
on:
issue_comment:
types: [created, deleted]
```
The `issue_comment` event occurs for comments on both issues and pull requests. To determine whether the `issue_comment` event was triggered from an issue or pull request, you can check the event payload for the `issue.pull_request` property and use it as a condition to skip a job.
For example, you can choose to run the `pr_commented` job when comment events occur in a pull request, and the `issue_commented` job when comment events occur in an issue.
{% raw %}
```yaml
on: issue_comment
jobs:
pr_commented:
# This job only runs for pull request comments
name: PR comment
if: ${{ github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo "Comment on PR #${{ github.event.issue.number }}"
issue_commented:
# This job only runs for issue comments
name: Issue comment
if: ${{ !github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo "Comment on issue #${{ github.event.issue.number }}"
```
{% endraw %}
### `issues`
Runs your workflow anytime the `issues` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Issues](/rest/reference/issues)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`issues`](/webhooks/event-payloads/#issues) | - `opened`<br/>- `edited`<br/>- `deleted`<br/>- `transferred`<br/>- `pinned`<br/>- `unpinned`<br/>- `closed`<br/>- `reopened`<br/>- `assigned`<br/>- `unassigned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `locked`<br/>- `unlocked`<br/>- `milestoned`<br/> - `demilestoned` | Last commit on default branch | Default branch |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when an issue has been `opened`, `edited`, or `milestoned`.
```yaml
on:
issues:
types: [opened, edited, milestoned]
```
### `label`
Runs your workflow anytime the `label` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Labels](/rest/reference/issues#labels)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`label`](/webhooks/event-payloads/#label) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | Last commit on default branch | Default branch |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a label has been `created` or `deleted`.
```yaml
on:
label:
types: [created, deleted]
```
### `milestone`
Runs your workflow anytime the `milestone` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Milestones](/rest/reference/issues#milestones)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`milestone`](/webhooks/event-payloads/#milestone) | - `created`<br/>- `closed`<br/>- `opened`<br/>- `edited`<br/>- `deleted`<br/> | Last commit on default branch | Default branch |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a milestone has been `opened` or `deleted`.
```yaml
on:
milestone:
types: [opened, deleted]
```
### `page_build`
Runs your workflow anytime someone pushes to a {% data variables.product.product_name %} Pages-enabled branch, which triggers the `page_build` event. For information about the REST API, see "[Pages](/rest/reference/repos#pages)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`page_build`](/webhooks/event-payloads/#page_build) | n/a | Last commit on default branch | n/a |
For example, you can run a workflow when the `page_build` event occurs.
```yaml
on:
page_build
```
### `project`
Runs your workflow anytime the `project` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Projects](/rest/reference/projects)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`project`](/webhooks/event-payloads/#project) | - `created`<br/>- `updated`<br/>- `closed`<br/>- `reopened`<br/>- `edited`<br/>- `deleted`<br/> | Last commit on default branch | Default branch |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a project has been `created` or `deleted`.
```yaml
on:
project:
types: [created, deleted]
```
### `project_card`
Runs your workflow anytime the `project_card` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Project cards](/rest/reference/projects#cards)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`project_card`](/webhooks/event-payloads/#project_card) | - `created`<br/>- `moved`<br/>- `converted` to an issue<br/>- `edited`<br/>- `deleted` | Last commit on default branch | Default branch |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a project card has been `opened` or `deleted`.
```yaml
on:
project_card:
types: [created, deleted]
```
### `project_column`
Runs your workflow anytime the `project_column` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Project columns](/rest/reference/projects#columns)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`project_column`](/webhooks/event-payloads/#project_column) | - `created`<br/>- `updated`<br/>- `moved`<br/>- `deleted` | Last commit on default branch | Default branch |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a project column has been `created` or `deleted`.
```yaml
on:
project_column:
types: [created, deleted]
```
### `public`
Runs your workflow anytime someone makes a private repository public, which triggers the `public` event. For information about the REST API, see "[Edit repositories](/rest/reference/repos#edit)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`public`](/webhooks/event-payloads/#public) | n/a | Last commit on default branch | Default branch |
For example, you can run a workflow when the `public` event occurs.
```yaml
on:
public
```
### `pull_request`
Runs your workflow anytime the `pull_request` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Pull requests](/rest/reference/pulls)."
{% note %}
**Notes:**
- By default, a workflow only runs when a `pull_request`'s activity type is `opened`, `synchronize`, or `reopened`. To trigger workflows for more activity types, use the `types` keyword.
- Workflows will not run on `pull_request` activity if the pull request has a merge conflict. The merge conflict must be resolved first.
{% endnote %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`pull_request`](/webhooks/event-payloads/#pull_request) | - `assigned`<br/>- `unassigned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `opened`<br/>- `edited`<br/>- `closed`<br/>- `reopened`<br/>- `synchronize`<br/>- `converted_to_draft`<br/>- `ready_for_review`<br/>- `locked`<br/>- `unlocked` <br/>- `review_requested` <br/>- `review_request_removed`{% ifversion fpt or ghes > 3.0 or ghae or ghec %} <br/>- `auto_merge_enabled` <br/>- `auto_merge_disabled`{% endif %} | Last merge commit on the `GITHUB_REF` branch | PR merge branch `refs/pull/:prNumber/merge` |
You extend or limit the default activity types using the `types` keyword. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions#onevent_nametypes)."
For example, you can run a workflow when a pull request has been `assigned`, `opened`, `synchronize`, or `reopened`.
```yaml
on:
pull_request:
types: [assigned, opened, synchronize, reopened]
```
{% data reusables.developer-site.pull_request_forked_repos_link %}
### `pull_request_review`
Runs your workflow anytime the `pull_request_review` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Pull request reviews](/rest/reference/pulls#reviews)."
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`pull_request_review`](/webhooks/event-payloads/#pull_request_review) | - `submitted`<br/>- `edited`<br/>- `dismissed` | Last merge commit on the `GITHUB_REF` branch | PR merge branch `refs/pull/:prNumber/merge` |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a pull request review has been `edited` or `dismissed`.
```yaml
on:
pull_request_review:
types: [edited, dismissed]
```
{% data reusables.developer-site.pull_request_forked_repos_link %}
### `pull_request_review_comment`
Runs your workflow anytime a comment on a pull request's unified diff is modified, which triggers the `pull_request_review_comment` event. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see [Review comments](/rest/reference/pulls#comments).
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`pull_request_review_comment`](/webhooks/event-payloads/#pull_request_review_comment) | - `created`<br/>- `edited`<br/>- `deleted`| Last merge commit on the `GITHUB_REF` branch | PR merge branch `refs/pull/:prNumber/merge` |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a pull request review comment has been `created` or `deleted`.
```yaml
on:
pull_request_review_comment:
types: [created, deleted]
```
{% data reusables.developer-site.pull_request_forked_repos_link %}
### `pull_request_target`
This event runs in the context of the base of the pull request, rather than in the merge commit as the `pull_request` event does. This prevents executing unsafe workflow code from the head of the pull request that could alter your repository or steal any secrets you use in your workflow. This event allows you to do things like create workflows that label and comment on pull requests based on the contents of the event payload.
{% warning %}
**Warning:** The `pull_request_target` event is granted a read/write repository token and can access secrets, even when it is triggered from a fork. Although the workflow runs in the context of the base of the pull request, you should make sure that you do not check out, build, or run untrusted code from the pull request with this event. Additionally, any caches share the same scope as the base branch, and to help prevent cache poisoning, you should not save the cache if there is a possibility that the cache contents were altered. For more information, see "[Keeping your GitHub Actions and workflows secure: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests)" on the GitHub Security Lab website.
{% endwarning %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`pull_request_target`](/webhooks/event-payloads/#pull_request) | - `assigned`<br/>- `unassigned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `opened`<br/>- `edited`<br/>- `closed`<br/>- `reopened`<br/>- `synchronize`<br/>- `converted_to_draft`<br/>- `ready_for_review`<br/>- `locked`<br/>- `unlocked` <br/>- `review_requested` <br/>- `review_request_removed`{% ifversion fpt or ghes > 3.0 or ghae or ghec %} <br/>- `auto_merge_enabled` <br/>- `auto_merge_disabled`{% endif %} | Last commit on the PR base branch | PR base branch |
By default, a workflow only runs when a `pull_request_target`'s activity type is `opened`, `synchronize`, or `reopened`. To trigger workflows for more activity types, use the `types` keyword. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions#onevent_nametypes)."
For example, you can run a workflow when a pull request has been `assigned`, `opened`, `synchronize`, or `reopened`.
```yaml
on:
pull_request_target:
types: [assigned, opened, synchronize, reopened]
```
### `push`
{% note %}
**Note:** The webhook payload available to GitHub Actions does not include the `added`, `removed`, and `modified` attributes in the `commit` object. You can retrieve the full commit object using the REST API. For more information, see "[Get a commit](/rest/reference/commits#get-a-commit)".
{% endnote %}
Runs your workflow when someone pushes to a repository branch, which triggers the `push` event.
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`push`](/webhooks/event-payloads/#push) | n/a | Commit pushed, unless deleting a branch (when it's the default branch) | Updated ref |
For example, you can run a workflow when the `push` event occurs.
```yaml
on:
push
```
### `registry_package`
Runs your workflow anytime a package is `published` or `updated`. For more information, see "[Managing packages with {% data variables.product.prodname_registry %}](/github/managing-packages-with-github-packages)."
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`registry_package`](/webhooks/event-payloads/#package) | - `published`<br/>- `updated` | Commit of the published package | Branch or tag of the published package |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a package has been `published`.
```yaml
on:
registry_package:
types: [published]
```
### `release`
{% note %}
**Note:** The `release` event is not triggered for draft releases.
{% endnote %}
Runs your workflow anytime the `release` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Releases](/rest/reference/repos#releases)."
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`release`](/webhooks/event-payloads/#release) | - `published` <br/>- `unpublished` <br/>- `created` <br/>- `edited` <br/>- `deleted` <br/>- `prereleased`<br/> - `released` | Last commit in the tagged release | Tag of release |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a release has been `published`.
```yaml
on:
release:
types: [published]
```
{% note %}
**Note:** The `prereleased` type will not trigger for pre-releases published from draft releases, but the `published` type will trigger. If you want a workflow to run when stable *and* pre-releases publish, subscribe to `published` instead of `released` and `prereleased`.
{% endnote %}
### `status`
Runs your workflow anytime the status of a Git commit changes, which triggers the `status` event. For information about the REST API, see [Statuses](/rest/reference/repos#statuses).
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`status`](/webhooks/event-payloads/#status) | n/a | Last commit on default branch | n/a |
For example, you can run a workflow when the `status` event occurs.
```yaml
on:
status
```
### `watch`
Runs your workflow anytime the `watch` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Starring](/rest/reference/activity#starring)."
{% data reusables.github-actions.branch-requirement %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`watch`](/webhooks/event-payloads/#watch) | - `started` | Last commit on default branch | Default branch |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when someone stars a repository, which is the `started` activity type that triggers the watch event.
```yaml
on:
watch:
types: [started]
```
### `workflow_run`
{% data reusables.webhooks.workflow_run_desc %}
{% note %}
**Notes:**
* This event will only trigger a workflow run if the workflow file is on the default branch.
* You can't use `workflow_run` to chain together more than three levels of workflows. For example, if you attempt to trigger five workflows (named `B` to `F`) to run sequentially after an initial workflow `A` has run (that is: `A` → `B` → `C` → `D` → `E` → `F`), workflows `E` and `F` will not be run.
{% endnote %}
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------- | -------------- | ------------ | -------------|
| [`workflow_run`](/webhooks/event-payloads/#workflow_run) | - `completed`<br/>- `requested` | Last commit on default branch | Default branch |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
If you need to filter branches from this event, you can use `branches` or `branches-ignore`.
In this example, a workflow is configured to run after the separate "Run Tests" workflow completes.
```yaml
on:
workflow_run:
workflows: ["Run Tests"]
branches: [main]
types:
- completed
- requested
```
To run a workflow job conditionally based on the result of the previous workflow run, you can use the [`jobs.<job_id>.if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif) or [`jobs.<job_id>.steps[*].if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsif) conditional combined with the `conclusion` of the previous run. For example:
```yaml
on:
workflow_run:
workflows: ["Build"]
types: [completed]
jobs:
on-success:
runs-on: ubuntu-latest
if: {% raw %}${{ github.event.workflow_run.conclusion == 'success' }}{% endraw %}
steps:
...
on-failure:
runs-on: ubuntu-latest
if: {% raw %}${{ github.event.workflow_run.conclusion == 'failure' }}{% endraw %}
steps:
...
```
## Triggering new workflows using a personal access token
{% data reusables.github-actions.actions-do-not-trigger-workflows %} For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
If you would like to trigger a workflow from a workflow run, you can trigger the event using a personal access token. You'll need to create a personal access token and store it as a secret. To minimize your {% data variables.product.prodname_actions %} usage costs, ensure that you don't create recursive or unintended workflow runs. For more information on storing a personal access token as a secret, see "[Creating and storing encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)."

185
translations/es-ES/content/actions/learn-github-actions/managing-complex-workflows.md
View File

@@ -1,185 +0,0 @@
---
title: Administrar flujos de trabajo complejos
shortTitle: Administrar flujos de trabajo complejos
intro: 'Esta guía te muestra cómo utilizar las características avanzadas de {% data variables.product.prodname_actions %} con administración de secretos, jobs dependientes, almacenamiento en caché, matrices de compilación,{% ifversion fpt or ghes > 3.0 or ghae or ghec %} ambientes,{% endif %}y etiquetas.'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: how_to
topics:
- Workflows
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Resumen
Este artículo describe algunas de las características avanzadas de las {% data variables.product.prodname_actions %} que te ayudan a crear flujos de trabajo más complejos.
## Almacenar secretos
Si tus flujos de trabajo utilizan datos sensibles tales como contraseñas o certificados, puedes guardarlos en {% data variables.product.prodname_dotcom %} como _secretos_ y luego usarlos en tus flujos de trabajo como variables de ambiente. Esto significa que podrás crear y compartir flujos de trabajo sin tener que embeber valores sensibles directamente en el flujo de trabajo de YAML.
Esta acción de ejemplo ilustra cómo referenciar un secreto existente como una variable de ambiente y enviarla como parámetro a un comando de ejemplo.
{% raw %}
```yaml
jobs:
example-job:
runs-on: ubuntu-latest
steps:
- name: Retrieve secret
env:
super_secret: ${{ secrets.SUPERSECRET }}
run: |
example-command "$super_secret"
```
{% endraw %}
Para obtener más información, consulta "[Crear y almacenar secretos cifrados](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)".
## Crear jobs dependientes
Predeterminadamente, los jobs en tu flujo de trabajo se ejecutan todos en paralelo y al mismo tiempo. Así que, si tienes un job que solo debe ejecutarse después de que se complete otro job, puedes utilizar la palabra clave `needs` para crear esta dependencia. Si un de los jobs falla, todos los jobs dependientes se omitirán; sin embargo, si necesitas que los jobs sigan, puedes definir esto utilizando la declaración condicional [`if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif).
En este ejemplo, los jobs de `setup`, `build`, y `test` se ejecutan en serie, y `build` y `test` son dependientes de que el job que las precede se complete con éxito:
```yaml
jobs:
setup:
runs-on: ubuntu-latest
steps:
- run: ./setup_server.sh
build:
needs: setup
runs-on: ubuntu-latest
steps:
- run: ./build_server.sh
test:
needs: build
runs-on: ubuntu-latest
steps:
- run: ./test_server.sh
```
Para obtener más información, consulta la parte de [`jobs.<job_id>.needs`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds).
## Utilizar una matriz de compilaciones
Puedes utilizar una matriz de compilaciones si quieres que tu flujo de trabajo ejecute pruebas a través de varias combinaciones de sistemas operativos, plataformas y lenguajes. La matriz de compilaciones se crea utilizando la palabra clave `strategy`, la cual recibe las opciones de compilación como un arreglo. Por ejemplo, esta matriz de compilaciones ejecutará el job varias veces, utilizando diferentes versiones de Node.js:
{% raw %}
```yaml
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node: [6, 8, 10]
steps:
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node }}
```
{% endraw %}
Para obtener más información, consulta la parte de [`jobs.<job_id>.strategy.matrix`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix).
{% ifversion fpt or ghec %}
## Almacenar dependencias en caché
Los ejecutores hospedados en {% data variables.product.prodname_dotcom %} se inician como ambientes nuevos para cada job, así que, si tus jobs utilizan dependencias a menudo, puedes considerar almacenar estos archivos en caché para ayudarles a mejorar el rendimiento. Una vez que se crea el caché, estará disponible para todos los flujos de trabajo en el mismo repositorio.
Este ejemplo ilustra cómo almacenar el directorio `~/.npm` en el caché:
{% raw %}
```yaml
jobs:
example-job:
steps:
- name: Cache node modules
uses: actions/cache@v2
env:
cache-name: cache-node-modules
with:
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
```
{% endraw %}
Para obtener más información, consulta la sección "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Almacenar las dependencias en caché para agilizar los flujos de trabajo</a>".
{% endif %}
## Usar bases de datos y contenedores de servicio
Si tu job requiere de un servicio de caché o de base de datos, puedes utilizar la palabra clave [`services`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idservices) para crear un contenedor efímero para almacenar el servicio; el contenedor resultante estará entonces disponible para todos los pasos de ese job y se eliminará cuando el job se haya completado. Este ejemplo ilustra como un job puede utilizar `services` para crear un contenedor de `postgres` y luego utilizar a `node` para conectarse al servicio.
```yaml
jobs:
container-job:
runs-on: ubuntu-latest
container: node:10.18-jessie
services:
postgres:
image: postgres
steps:
- name: Check out repository code
uses: actions/checkout@v2
- name: Install dependencies
run: npm ci
- name: Connect to PostgreSQL
run: node client.js
env:
POSTGRES_HOST: postgres
POSTGRES_PORT: 5432
```
Para obtener más información, consulta la sección "[Utilizar bases de datos y contenedores de servicios](/actions/configuring-and-managing-workflows/using-databases-and-service-containers)".
## Utilizar etiquetas para enrutar los flujos de trabajo
Esta característica te ayuda a asignar jobs a un ejecutor hospedado específico. Si quieres asegurarte de que un tipo específico de ejecutor procesará tu job, puedes utilizar etiquetas para controlar donde se ejecutan los jobs. Puedes asignar etiquetas a un ejecutor auto-hospedado adicionalmente a su etiqueta predeterminada de `self-hosted`. Entonces, puedes referirte a estas etiquetas en tu flujo de trabajo de YAML, garantizando que el job se enrute de forma predecible.{% ifversion not ghae %}Los ejecutores hospedados en {% data variables.product.prodname_dotcom %} tienen asignadas etiquetas predefinidas.{% endif %}
Este ejemplo muestra como un flujo de trabajo puede utilizar etiquetas para especificar el ejecutor requerido:
```yaml
jobs:
example-job:
runs-on: [self-hosted, linux, x64, gpu]
```
Un flujo de trabajo solo se ejecutará en un ejecutor que tenga todas las etiquetas en el arreglo `runs-on`. El job irá preferencialmente a un ejecutor auto-hospedado inactivo con las etiquetas especificadas. Si no hay alguno disponible y existe un ejecutor hospedado en {% data variables.product.prodname_dotcom %} con las etiquetas especificadas, el job irá a un ejecutor hospedado en {% data variables.product.prodname_dotcom %}.
Para aprender más acerca de las etiquetas auto-hospedadas, consulta la sección ["Utilizar etiquetas con los ejecutores auto-hospedados](/actions/hosting-your-own-runners/using-labels-with-self-hosted-runners)".
{% ifversion fpt or ghes %}
Para aprender más sobre
las etiquetas de los ejecutores hospedados en {% data variables.product.prodname_dotcom %}, consulta la sección ["Ejecutores compatibles y recursos de hardware"](/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources).
{% endif %}
{% data reusables.actions.reusable-workflows %}
{% ifversion fpt or ghes > 3.0 or ghae or ghec %}
## Utilizar ambientes
Puedes configurr ambientes con reglas de protección y secretos. Cad job en un flujo de trabajo puede referenciar un solo ambiente. Cualquier regla de protección que se configure para el ambiente debe pasar antes de que un job que referencia al ambiente se envíe a un ejecutor. Para obtener más información, consulta la sección "[Utilizar ambientes para despliegue](/actions/deployment/using-environments-for-deployment)".
{% endif %}
## Utilizar flujos de trabajo iniciales
{% data reusables.actions.workflow-template-overview %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.actions-tab %}
1. Si tu repositorio ya cuenta con flujos de trabajo: En la esquina superior izquierda, da clic sobre **Flujo de trabajo nuevo**. ![Crear un nuevo flujo de trabajo](/assets/images/help/repository/actions-new-workflow.png)
1. Debajo del nombre del flujo de trabajo inicial que te gustaría utilizar, haz clic en **Configurar este flujo de trabajo**. ![Configurar este flujo de trabajo](/assets/images/help/settings/actions-create-starter-workflow.png)
## Pasos siguientes
Para seguir aprendiendo sobre las {% data variables.product.prodname_actions %}, consulta la sección "[Compartir flujos de trabajo, secretos y ejecutores con tu organización](/actions/learn-github-actions/sharing-workflows-secrets-and-runners-with-your-organization)".

304
translations/es-ES/content/actions/learn-github-actions/reusing-workflows.md
View File

@@ -1,304 +0,0 @@
---
title: Reutilizar flujos de trabajo
shortTitle: Reutilizar flujos de trabajo
intro: Aprende cómo evitar la duplicación al crear un flujo de trabajo reusando los flujos existentes.
miniTocMaxHeadingLevel: 3
versions:
fpt: '*'
ghec: '*'
ghes: '>=3.4'
ghae: issue-4757
type: how_to
topics:
- Workflows
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Resumen
En vez de copiar y pegar desde un flujo de trabajo hacia otro, puedes hacer flujos de trabajo reutilizables. Tú y cualquiera que tenga acceso a un flujo de trabajo reutilizable pueden entonces llamarlo desde otro flujo.
El reutilizar flujos de trabajo evita la duplicación. Esto hace que los flujos de trabajo se puedan mantener más fácilmente y te permite crear flujos de trabajo nuevos más fácilmente compilando sobre el trabajo de los demás, tal como lo haces con las acciones. La reutilización de flujos de trabajo también promueve las mejores prácticas al ayudarte a utilizar los flujos de trabajo que están bien diseñados, que ya se han probado y cuya efectividad ya se comprobó. Tu organización puede crear una librería de flujos de trabajo reutilizables que puede mantenerse centralmente.
El siguiente diagrama muestra tres jobs de compilación en la parte izquierda del mismo. Después de que cada uno de estos jobs se complete con éxito, se ejecutará un job dependiente llamado "Deploy". Este job crea un flujo de trabajo reutilizable que contiene tres jobs: "Staging", "Review" y "Production". El job de despliegue "Production" solo se ejecuta después de que el job "Staging" se haya completado con éxito. El utilizar un flujo de trabajo reutilizable para ejecutar jobs de despliegue te permite ejecutarlos para cada compilación sin duplicar el código en los flujos de trabajo.
![Diagrama de un flujo de trabajo reutilizable para despliegue](/assets/images/help/images/reusable-workflows-ci-cd.png)
A un flujo de trabajo que utiliza otro flujo de trabajo se le llama flujo de trabajo "llamante". El flujo de trabajo reutilizable es un flujo "llamado". Un flujo de trabajo llamante puede utilizar varios flujos de trabajo llamados. Cada flujo de trabajo llamado se referencia en una línea simple. El resultado es que el archivo de flujo de trabajo llamante podrá contener solo unas cuantas líneas de YAML, pero podría realizar una cantidad grande de tareas cuando se ejecute. Cuando reutilizas un flujo de trabajo, se utiliza todo el flujo de trabajo llamado justo como si fuera parte del flujo de trabajo llamante.
Si utilizas un flujo de trabajo desde un repositorio diferente, cualquier acción en el flujo de trabajo llamado se ejecutará como si fuera parte del llamante. Por ejemplo, si el flujo de trabajo llamado utiliza `actions/checkout`, la acción verifica el contenido del repositorio que hospeda el flujo de trabajo llamante y no el llamado.
Cuando un flujo de trabajo llamante activa uno reutilizable, el contexto `github` siempre se asocia con el flujo llamante. Se otorga acceso automáticamente al flujo de trabajo llamado para `github.token` y `secrets.GITHUB_TOKEN`. Para obtener más información sobre el contexto `github`, consulta la sección "[Sintaxis de contexto y expresión para GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)".
### Reusable workflows and starter workflow
Starter workflow allow everyone in your organization who has permission to create workflows to do so more quickly and easily. When people create a new workflow, they can choose a starter workflow and some or all of the work of writing the workflow will be done for them. Inside starter workflow, you can also reference reusable workflows to make it easy for people to benefit from reusing centrally managed workflow code. If you use a tag or branch name when referencing the reusable workflow then you can ensure that everyone who reuses that workflow will always be using the same YAML code. However, if you reference a reusable workflow by a tag or branch, be sure that you can trust that version of the workflow. Para obtener más información, consulta la sección "[Fortalecimiento de seguridad para las {% data variables.product.prodname_actions %}](/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows)".
For more information, see "[Creating starter workflows for your organization](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)."
## Acceso a los flujos de trabajo reutilizables
A reusable workflow can be used by another workflow if {% ifversion ghes or ghec or ghae %}any{% else %}either{% endif %} of the following is true:
* Ambos flujos de trabajo están en el mismo repositorio.
* The called workflow is stored in a public repository.{% ifversion ghes or ghec or ghae %}
* El flujo de trabajo llamado se almacena en un repositorio interno y los ajustes de dicho repositorio permiten que se acceda a él. Para obtener más información, consulta la sección "[Administrar los ajustes de las {% data variables.product.prodname_actions %} en un repositorio](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository)".{% endif %}
## Using runners
{% ifversion fpt or ghes or ghec %}
### Utilizar los ejecutores hospedados en GitHub
The assignment of {% data variables.product.prodname_dotcom %}-hosted runners is always evaluated using only the caller's context. Billing for {% data variables.product.prodname_dotcom %}-hosted runners is always associated with the caller. The caller workflow cannot use {% data variables.product.prodname_dotcom %}-hosted runners from the called repository. Para obtener más información, consulta la sección "[Acerca de los ejecutores hospedados en {% data variables.product.prodname_dotcom %}](/actions/using-github-hosted-runners/about-github-hosted-runners)".
### Using self-hosted runners
{% endif %}
Called workflows can access self-hosted runners from 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{% ifversion ghes or ghec or ghae %} or enterprise{% endif %}, provided that the runner has been made available to the caller repository
## Limitaciones
* Los flujos de trabajo reutilizables no pueden llamar a otros que también sean reutilizables.
* Los flujos de trabajo solo podrán usar a los reutilizables que se encuentren almacenados en un repositorio privado en caso de que estos también se encuentren en el mismo repositorio.
* Ninguna variable de ambiente que se configure en un contexto de `env` que se defina a nivel del flujo de trabajo en aquél llamante se propagará al flujo llamado. Para obtener más información sobre el contexto `env`, consulta la sección "[Sintaxis de contexto y expresión para GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#env-context)".
* The `strategy` property is not supported in any job that calls a reusable workflow.
## Crear un flujo de trabajo reutilizable
Los flujos de trabajo reutilizables son archivos con formato YAML, muy similares a cualquier otro archivo de flujo de trabajo. Tal como con otros flujos de trabajo, puedes ubicar los reutilizables en el directorio `.github/workflows` de un repositorio. Los subdirectorios del directorio `workflows` no son compatibles.
Para que un flujo de trabajo sea reutilizable, los valores de `on` deben incluir `workflow_call`:
```yaml
on:
workflow_call:
```
### Using inputs and secrets in a reusable workflow
Puedes definir entradas y secretos, las cuales pueden pasarse desde el flujo de trabajo llamante y luego utilizarse dentro del flujo llamado. There are three stages to using an input or a secret in a reusable workflow.
1. In the reusable workflow, use the `inputs` and `secrets` keywords to define inputs or secrets that will be passed from a caller workflow.
{% raw %}
```yaml
on:
workflow_call:
inputs:
username:
required: true
type: string
secrets:
envPAT:
required: true
```
{% endraw %}
Para encontrar los detalles de la sintaxis para definir entradas y secretos, consulta [`on.workflow_call.inputs`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callinputs) y [`on.workflow_call.secrets`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callsecrets).
1. Reference the input or secret in the reusable workflow.
{% raw %}
```yaml
jobs:
reusable_workflow_job:
runs-on: ubuntu-latest
environment: production
steps:
- uses: ./.github/actions/my-action@v1
with:
username: ${{ inputs.username }}
token: ${{ secrets.envPAT }}
```
{% endraw %}
In the example above, `envPAT` is an environment secret that's been added to the `production` environment. This environment is therefore referenced within the job.
{% note %}
**Note**: Environment secrets are encrypted strings that are stored in an environment that you've defined for a repository. Environment secrets are only available to workflow jobs that reference the appropriate environment. Para obtener más información, consulta la sección "[Utilizar ambientes para despliegue](/actions/deployment/targeting-different-environments/using-environments-for-deployment#environment-secrets)".
{% endnote %}
1. Pass the input or secret from the caller workflow.
{% indented_data_reference reusables.actions.pass-inputs-to-reusable-workflows spaces=3 %}
### Flujo de trabajo reutilizable de ejemplo
This reusable workflow file named `workflow-B.yml` (we'll refer to this later in the [example caller workflow](#example-caller-workflow)) takes an input string and a secret from the caller workflow and uses them in an action.
{% raw %}
```yaml{:copy}
name: Reusable workflow example
on:
workflow_call:
inputs:
username:
required: true
type: string
secrets:
token:
required: true
jobs:
example_job:
name: Pass input and secrets to my-action
runs-on: ubuntu-latest
steps:
- uses: ./.github/actions/my-action@v1
with:
username: ${{ inputs.username }}
token: ${{ secrets.token }}
```
{% endraw %}
## Llamar a un flujo de trabajo reutilizable
Se llama a un flujo de trabajo reutilizable utilizando la palabra clave `uses`. A diferencia de cuando utilizas acciones en un flujo de trabajo, los flujos de trabajo reutilizables se llaman directamente desde un job y no dentro de los pasos de un job.
[`jobs.<job_id>.uses`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_iduses)
Se referencian los archivos de flujo de trabajo reutilizables utilizando la sintaxis:
`{owner}/{repo}/{path}/{filename}@{ref}`
Puedes llamar a flujos de trabajo múltiples, referenciando cada uno en un job separado.
{% data reusables.actions.uses-keyword-example %}
### Pasar entradas y secretos a un flujo de trabajo reutilizable
{% data reusables.actions.pass-inputs-to-reusable-workflows%}
### Palabras clave compatibles con los jobs que llaman a un flujo de trabajo reutilizable
Cuando llamas a un flujo de trabajo reutilizable, solo puedes utilizar las siguientes palabras clave en el job que contiene la llamada:
* [`jobs.<job_id>.name`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idname)
* [`jobs.<job_id>.uses`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_iduses)
* [`jobs.<job_id>.with`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idwith)
* [`jobs.<job_id>.with.<input_id>`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idwithinput_id)
* [`jobs.<job_id>.secrets`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsecrets)
* [`jobs.<job_id>.secrets.<secret_id>`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsecretssecret_id)
* [`jobs.<job_id>.needs`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)
* [`jobs.<job_id>.if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif)
* [`jobs.<job_id>.permissions`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idpermissions)
{% note %}
**Nota:**
* Si no se especifica `jobs.<job_id>.permissions` en el job de llamada, el flujo de trabajo llamado tendrá los permisos predefinidos para el `GITHUB_TOKEN`. Para obtener más información, consulta la sección "[Autenticación en un flujo de trabajo](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)".
* Los permisos del `GITHUB_TOKEN` que se pasaron del flujo de trabajo llamante solo pueden bajarse de nivel (no elevarse) a través del flujo de trabajo llamado.
{% endnote %}
### Flujo de trabajo llamante de ejemplo
Este archivo de flujo de trabajo llama a otros dos archivos de flujo de trabajo. The second of these, `workflow-B.yml` (shown in the [example reusable workflow](#example-reusable-workflow)), is passed an input (`username`) and a secret (`token`).
{% raw %}
```yaml{:copy}
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:
uses: octo-org/example-repo/.github/workflows/workflow-B.yml@main
with:
username: mona
secrets:
token: ${{ secrets.TOKEN }}
```
{% endraw %}
## Using outputs from a reusable workflow
A reusable workflow may generate data that you want to use in the caller workflow. To use these outputs, you must specify them as the outputs of the reusable workflow.
The following reusable workflow has a single job containing two steps. In each of these steps we set a single word as the output: "hello" and "world." In the `outputs` section of the job, we map these step outputs to job outputs called: `output1` and `output2`. In the `on.workflow_call.outputs` section we then define two outputs for the workflow itself, one called `firstword` which we map to `output1`, and one called `secondword` which we map to `output2`.
{% raw %}
```yaml{:copy}
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 "::set-output name=firstword::hello"
- id: step2
run: echo "::set-output name=secondword::world"
```
{% endraw %}
We can now use the outputs in the caller workflow, in the same way you would use the outputs from a job within the same workflow. We reference the outputs using the names defined at the workflow level in the reusable workflow: `firstword` and `secondword`. In this workflow, `job1` calls the reusable workflow and `job2` prints the outputs from the reusable workflow ("hello world") to standard output in the workflow log.
{% raw %}
```yaml{:copy}
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 }}
```
{% endraw %}
For more information on using job outputs, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idoutputs)."
## Monitoring which workflows are being used
Puedes utilizar la API de REST de {% data variables.product.prodname_dotcom %} para monitorear cómo se utilizan los flujos de trabajo reutilizables. La acción de bitácora de auditoría `prepared_workflow_job` se activa cuando se inicia un job de flujo de trabajo. Entre los datos registrados se incluyen:
* `repo` - la organización/repositorio en donde se ubica el job de flujo de trabajo. Para un job que llama a otro flujo de trabajo, esta es la organización/repositorio del flujo llamador.
* `@timestamp` - la fecha y hora en las que se inició el job, en formato epoch de Unix.
* `job_name` - el nombre del job que se ejecutó.
* `job_workflow_ref` - el flujo de trabajo que se utilizó, en formato `{owner}/{repo}/{path}/{filename}@{ref}`. Para un job que llama a otro flujo de trabajo, esto identifica al flujo llamado.
Para obtener más información sobre cómo utilizar la API de REST para consultar la bitácora de auditoría de una organización, consulta la sección "[Organizaciones](/rest/reference/orgs#get-the-audit-log-for-an-organization)".
{% note %}
**Nota**: Los datos de auditoría de `prepared_workflow_job` solo pueden verse utilizando la API de REST. No se puede ver en la interfaz web de {% data variables.product.prodname_dotcom %} ni se incluye en los datos de auditoría exportados en JSON/CSV.
{% endnote %}
## Pasos siguientes
Para seguir aprendiendo sobre las {% data variables.product.prodname_actions %}, consulta la sección "[Eventos que activan flujos de trabajo](/actions/learn-github-actions/events-that-trigger-workflows)".

54
translations/es-ES/content/actions/learn-github-actions/sharing-workflows-secrets-and-runners-with-your-organization.md
View File

@@ -1,54 +0,0 @@
---
title: 'Compartir flujos de trabajo, secretos y ejecutores con tu organización'
shortTitle: Compartir flujos de trabajo con tu organización
intro: 'Aprende cómo puedes utilizar características de la organización para colaborar con tu equipo compartiendo flujos de trabajo iniciales, secretos y ejecutores auto-hospedados.'
redirect_from:
- /actions/learn-github-actions/sharing-workflows-with-your-organization
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: how_to
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Resumen
Si necesitas compartir flujos de trabajo y otras características de {% data variables.product.prodname_actions %} con tu equipo, entonces considera colaborar dentrod e una organización de {% data variables.product.prodname_dotcom %}. Una organización te permite almacenar centralmente y administrar secretos, artefactos y ejecutores auto-hospedados. You can also create starter workflow in the `.github` repository and share them with other users in your organization.
## Utilizar flujos de trabajo iniciales
{% data reusables.actions.workflow-organization-templates %} For more information, see "[Creating starter workflows for your organization](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)."
{% data reusables.actions.reusable-workflows %}
## Compartir secretos dentro de una organización
Puedes admnistrar tus secretos centralmente dentro de una organización y hacerlos disponibles para repositorios específicos. Esto también significa que púedes actualizar un secreto en una ubicación y hacer que el cambio aplique a todos los flujos de trabajo del repositorio que lo utilicen.
Cuando creas un secreto en una organización, puedes utilizar una política para limitar el acceso de los repositorios a este. Por ejemplo, puedes otorgar acceso a todos los repositorios, o limitarlo a solo los repositorios privados o a una lista específica de estos.
{% data reusables.github-actions.permissions-statement-secrets-organization %}
{% data reusables.organizations.navigate-to-org %}
{% data reusables.organizations.org_settings %}
{% data reusables.github-actions.sidebar-secret %}
1. Da clic en **Secreto nuevo**.
1. Teclea un nombre para tu secreto en el cuadro de entrada **Name**.
1. Ingresa el **Valor** para tu secreto.
1. Desde la lista desplegable **Acceso de los repositorios**, elige una política de acceso.
1. Haz clic en **Agregar secreto** (Agregar secreto).
## Compartir ejecutores auto-hospedados dentro de una organización
Los administradores de las organizaciones pueden agregar sus ejecutores auto-hospedados a grupos y luego crear políticas que controlen qué repositorios pueden acceder al grupo.
Para obtener más información, consulta la sección "[Administrar el acceso a los ejecutores auto-hospedados](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups)".
## Pasos siguientes
To continue learning about {% data variables.product.prodname_actions %}, see "[Creating starter workflows for your organization](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)."

54
translations/es-ES/content/actions/learn-github-actions/using-starter-workflows.md
View File

@@ -1,54 +0,0 @@
---
title: Utilizar flujos de trabajo iniciales
intro: '{% data variables.product.product_name %} provides starter workflows for a variety of languages and tooling.'
redirect_from:
- /articles/setting-up-continuous-integration-using-github-actions
- /github/automating-your-workflow-with-github-actions/setting-up-continuous-integration-using-github-actions
- /actions/automating-your-workflow-with-github-actions/setting-up-continuous-integration-using-github-actions
- /actions/building-and-testing-code-with-continuous-integration/setting-up-continuous-integration-using-github-actions
- /actions/guides/setting-up-continuous-integration-using-workflow-templates
- /actions/learn-github-actions/using-workflow-templates
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- Workflows
- CI
- CD
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## About starter workflows
{% data variables.product.product_name %} offers starter workflows for a variety of languages and tooling. Cuando configuras flujos de trabajo en tu repositorio, {% data variables.product.product_name %} analiza el código en tu repositorio y recomienda flujos de trabajo con base en el lenguaje y marco de trabajo de este. For example, if you use [Node.js](https://nodejs.org/en/), {% data variables.product.product_name %} will suggest a starter workflow file that installs your Node.js packages and runs your tests.{% if actions-starter-template-ui %} You can search and filter to find relevant starter workflows.{% endif %}
You can also create your own starter workflow to share with your organization. These starter workflows will appear alongside the {% data variables.product.product_name %}-provided starter workflows. For more information, see "[Creating starter workflows for your organization](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)."
## Utilizar flujos de trabajo iniciales
Anyone with write permission to a repository can set up {% data variables.product.prodname_actions %} starter workflows for CI/CD or other automation.
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.actions-tab %}
1. Si ya tienes un flujo de trabajo en tu repositorio, haz clic en **Flujo de trabajo nuevo**.
1. Find the starter workflow that you want to use, then click **Set up this workflow**.{% if actions-starter-template-ui %} To help you find the starter workflow that you want, you can search for keywords or filter by category.{% endif %}
1. If the starter workflow contains comments detailing additional setup steps, follow these steps. Many of the starter workflow have corresponding guides. Para obtener más información, consulta [las guías de {% data variables.product.prodname_actions %}](/actions/guides).
1. Some starter workflows use secrets. Por ejemplo, {% raw %}`${{ secrets.npm_token }}`{% endraw %}. If the starter workflow uses a secret, store the value described in the secret name as a secret in your repository. Para obtener más información, consulta "[Secretos cifrados](/actions/reference/encrypted-secrets)".
1. Opcionalmente, haz cambios adicionales. Por ejemplo, puede que quieras cambiar el valor de `on` para que este cambie cuando se ejecute el flujo de trabajo.
1. Haz clic en **Iniciar confirmación**.
1. Escribe un mensaje de confirmación y decide si lo quieres confirmar directamente en la rama predeterminada o si quieres abrir una solicitud de cambios.
## Leer más
- "[Acerca de la integración continua](/articles/about-continuous-integration)"
- "[Administrar las ejecuciones de flujos de trabajo](/actions/managing-workflow-runs)"
- "[Acerca del monitoreo y la solución de problemas](/actions/monitoring-and-troubleshooting-workflows/about-monitoring-and-troubleshooting)"
- "[Aprende sobre las {% data variables.product.prodname_actions %}](/actions/learn-github-actions)"
{% ifversion fpt or ghec %}
- "[Administrar la facturación de {% data variables.product.prodname_actions %}](/billing/managing-billing-for-github-actions)"
{% endif %}

411
translations/es-ES/content/actions/learn-github-actions/workflow-commands-for-github-actions.md
View File

@@ -1,411 +0,0 @@
---
title: Workflow commands for GitHub Actions
shortTitle: Workflow commands
intro: You can use workflow commands when running shell commands in a workflow or in an action's code.
redirect_from:
- /articles/development-tools-for-github-actions
- /github/automating-your-workflow-with-github-actions/development-tools-for-github-actions
- /actions/automating-your-workflow-with-github-actions/development-tools-for-github-actions
- /actions/reference/development-tools-for-github-actions
- /actions/reference/logging-commands-for-github-actions
- /actions/reference/workflow-commands-for-github-actions
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## About workflow commands
Actions can communicate with the runner machine to set environment variables, output values used by other actions, add debug messages to the output logs, and other tasks.
Most workflow commands use the `echo` command in a specific format, while others are invoked by writing to a file. For more information, see ["Environment files".](#environment-files)
``` bash
echo "::workflow-command parameter1={data},parameter2={data}::{command value}"
```
{% note %}
**Note:** Workflow command and parameter names are not case-sensitive.
{% endnote %}
{% warning %}
**Warning:** If you are using Command Prompt, omit double quote characters (`"`) when using workflow commands.
{% endwarning %}
## Using workflow commands to access toolkit functions
The [actions/toolkit](https://github.com/actions/toolkit) includes a number of functions that can be executed as workflow commands. Use the `::` syntax to run the workflow commands within your YAML file; these commands are then sent to the runner over `stdout`. For example, instead of using code to set an output, as below:
```javascript
core.setOutput('SELECTED_COLOR', 'green');
```
You can use the `set-output` command in your workflow to set the same value:
{% raw %}
``` yaml
- name: Set selected color
run: echo '::set-output name=SELECTED_COLOR::green'
id: random-color-generator
- name: Get color
run: echo "The selected color is ${{ steps.random-color-generator.outputs.SELECTED_COLOR }}"
```
{% endraw %}
The following table shows which toolkit functions are available within a workflow:
| Toolkit function | Equivalent workflow command |
| ----------------- | ------------- |
| `core.addPath` | Accessible using environment file `GITHUB_PATH` |
| `core.debug` | `debug` |{% ifversion fpt or ghes > 3.2 or ghae-issue-4929 or ghec %}
| `core.notice` | `notice` |{% endif %}
| `core.error` | `error` |
| `core.endGroup` | `endgroup` |
| `core.exportVariable` | Accessible using environment file `GITHUB_ENV` |
| `core.getInput` | Accessible using environment variable `INPUT_{NAME}` |
| `core.getState` | Accessible using environment variable `STATE_{NAME}` |
| `core.isDebug` | Accessible using environment variable `RUNNER_DEBUG` |
| `core.saveState` | `save-state` |
| `core.setCommandEcho` | `echo` |
| `core.setFailed` | Used as a shortcut for `::error` and `exit 1` |
| `core.setOutput` | `set-output` |
| `core.setSecret` | `add-mask` |
| `core.startGroup` | `group` |
| `core.warning` | `warning` |
## Setting an output parameter
```
::set-output name={name}::{value}
```
Sets an action's output parameter.
Optionally, you can also declare output parameters in an action's metadata file. For more information, see "[Metadata syntax for {% data variables.product.prodname_actions %}](/articles/metadata-syntax-for-github-actions#outputs)."
### Example
``` bash
echo "::set-output name=action_fruit::strawberry"
```
## Setting a debug message
```
::debug::{message}
```
Prints a debug message to the log. You must create a secret named `ACTIONS_STEP_DEBUG` with the value `true` to see the debug messages set by this command in the log. For more information, see "[Enabling debug logging](/actions/managing-workflow-runs/enabling-debug-logging)."
### Example
``` bash
echo "::debug::Set the Octocat variable"
```
{% ifversion fpt or ghes > 3.2 or ghae-issue-4929 or ghec %}
## Setting a notice message
```
::notice file={name},line={line},endLine={endLine},title={title}::{message}
```
Creates a notice message and prints the message to the log. {% data reusables.actions.message-annotation-explanation %}
{% data reusables.actions.message-parameters %}
### Example
``` bash
echo "::notice file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
```
{% endif %}
## Setting a warning message
```
::warning file={name},line={line},endLine={endLine},title={title}::{message}
```
Creates a warning message and prints the message to the log. {% data reusables.actions.message-annotation-explanation %}
{% data reusables.actions.message-parameters %}
### Example
``` bash
echo "::warning file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
```
## Setting an error message
```
::error file={name},line={line},endLine={endLine},title={title}::{message}
```
Creates an error message and prints the message to the log. {% data reusables.actions.message-annotation-explanation %}
{% data reusables.actions.message-parameters %}
### Example
``` bash
echo "::error file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
```
## Grouping log lines
```
::group::{title}
::endgroup::
```
Creates an expandable group in the log. To create a group, use the `group` command and specify a `title`. Anything you print to the log between the `group` and `endgroup` commands is nested inside an expandable entry in the log.
### Example
```bash
echo "::group::My title"
echo "Inside group"
echo "::endgroup::"
```
![Foldable group in workflow run log](/assets/images/actions-log-group.png)
## Masking a value in log
```
::add-mask::{value}
```
Masking a value prevents a string or variable from being printed in the log. Each masked word separated by whitespace is replaced with the `*` character. You can use an environment variable or string for the mask's `value`.
### Example masking a string
When you print `"Mona The Octocat"` in the log, you'll see `"***"`.
```bash
echo "::add-mask::Mona The Octocat"
```
### Example masking an environment variable
When you print the variable `MY_NAME` or the value `"Mona The Octocat"` in the log, you'll see `"***"` instead of `"Mona The Octocat"`.
```bash
MY_NAME="Mona The Octocat"
echo "::add-mask::$MY_NAME"
```
## Stopping and starting workflow commands
`::stop-commands::{endtoken}`
Stops processing any workflow commands. This special command allows you to log anything without accidentally running a workflow command. For example, you could stop logging to output an entire script that has comments.
To stop the processing of workflow commands, pass a unique token to `stop-commands`. To resume processing workflow commands, pass the same token that you used to stop workflow commands.
{% warning %}
**Warning:** Make sure the token you're using is randomly generated and unique for each run. As demonstrated in the example below, you can generate a unique hash of your `github.token` for each run.
{% endwarning %}
```
::{endtoken}::
```
### Example stopping and starting workflow commands
{% raw %}
```yaml
jobs:
workflow-command-job:
runs-on: ubuntu-latest
steps:
- name: disable workflow commands
run: |
echo '::warning:: this is a warning'
echo "::stop-commands::`echo -n ${{ github.token }} | sha256sum | head -c 64`"
echo '::warning:: this will NOT be a warning'
echo "::`echo -n ${{ github.token }} | sha256sum | head -c 64`::"
echo '::warning:: this is a warning again'
```
{% endraw %}
## Echoing command outputs
```
::echo::on
::echo::off
```
Enables or disables echoing of workflow commands. For example, if you use the `set-output` command in a workflow, it sets an output parameter but the workflow run's log does not show the command itself. If you enable command echoing, then the log shows the command, such as `::set-output name={name}::{value}`.
Command echoing is disabled by default. However, a workflow command is echoed if there are any errors processing the command.
The `add-mask`, `debug`, `warning`, and `error` commands do not support echoing because their outputs are already echoed to the log.
You can also enable command echoing globally by turning on step debug logging using the `ACTIONS_STEP_DEBUG` secret. For more information, see "[Enabling debug logging](/actions/managing-workflow-runs/enabling-debug-logging)". In contrast, the `echo` workflow command lets you enable command echoing at a more granular level, rather than enabling it for every workflow in a repository.
### Example toggling command echoing
```yaml
jobs:
workflow-command-job:
runs-on: ubuntu-latest
steps:
- name: toggle workflow command echoing
run: |
echo '::set-output name=action_echo::disabled'
echo '::echo::on'
echo '::set-output name=action_echo::enabled'
echo '::echo::off'
echo '::set-output name=action_echo::disabled'
```
The step above prints the following lines to the log:
```
::set-output name=action_echo::enabled
::echo::off
```
Only the second `set-output` and `echo` workflow commands are included in the log because command echoing was only enabled when they were run. Even though it is not always echoed, the output parameter is set in all cases.
## Sending values to the pre and post actions
You can use the `save-state` command to create environment variables for sharing with your workflow's `pre:` or `post:` actions. For example, you can create a file with the `pre:` action, pass the file location to the `main:` action, and then use the `post:` action to delete the file. Alternatively, you could create a file with the `main:` action, pass the file location to the `post:` action, and also use the `post:` action to delete the file.
If you have multiple `pre:` or `post:` actions, you can only access the saved value in the action where `save-state` was used. For more information on the `post:` action, see "[Metadata syntax for {% data variables.product.prodname_actions %}](/actions/creating-actions/metadata-syntax-for-github-actions#post)."
The `save-state` command can only be run within an action, and is not available to YAML files. The saved value is stored as an environment value with the `STATE_` prefix.
This example uses JavaScript to run the `save-state` command. The resulting environment variable is named `STATE_processID` with the value of `12345`:
``` javascript
console.log('::save-state name=processID::12345')
```
The `STATE_processID` variable is then exclusively available to the cleanup script running under the `main` action. This example runs in `main` and uses JavaScript to display the value assigned to the `STATE_processID` environment variable:
``` javascript
console.log("The running PID from the main action is: " + process.env.STATE_processID);
```
## Environment Files
During the execution of a workflow, the runner generates temporary files that can be used to perform certain actions. The path to these files are exposed via environment variables. You will need to use UTF-8 encoding when writing to these files to ensure proper processing of the commands. Multiple commands can be written to the same file, separated by newlines.
{% warning %}
**Warning:** On Windows, legacy PowerShell (`shell: powershell`) does not use UTF-8 by default. Make sure you write files using the correct encoding. For example, you need to set UTF-8 encoding when you set the path:
```yaml
jobs:
legacy-powershell-example:
uses: windows-2019
steps:
- shell: powershell
run: echo "mypath" | Out-File -FilePath $env:GITHUB_PATH -Encoding utf8 -Append
```
Or switch to PowerShell Core, which defaults to UTF-8:
```yaml
jobs:
modern-pwsh-example:
uses: windows-2019
steps:
- shell: pwsh
run: echo "mypath" | Out-File -FilePath $env:GITHUB_PATH -Append # no need for -Encoding utf8
```
More detail about UTF-8 and PowerShell Core found on this great [Stack Overflow answer](https://stackoverflow.com/a/40098904/162694):
> ### Optional reading: The cross-platform perspective: PowerShell _Core_:
> [PowerShell is now cross-platform](https://blogs.msdn.microsoft.com/powershell/2016/08/18/powershell-on-linux-and-open-source-2/), via its **[PowerShell _Core_](https://github.com/PowerShell/PowerShell)** edition, whose encoding - sensibly - **defaults to *BOM-less UTF-8***, in line with Unix-like platforms.
{% endwarning %}
## Setting an environment variable
``` bash
echo "{name}={value}" >> $GITHUB_ENV
```
Creates or updates an environment variable for any steps running next in a job. The step that creates or updates the environment variable does not have access to the new value, but all subsequent steps in a job will have access. Environment variables are case-sensitive and you can include punctuation.
{% note %}
**Note:** Environment variables must be explicitly referenced using the [`env` context](/actions/reference/context-and-expression-syntax-for-github-actions#env-context) in expression syntax or through use of the `$GITHUB_ENV` file directly; environment variables are not implicitly available in shell commands.
{% endnote %}
### Example
{% raw %}
```
steps:
- name: Set the value
id: step_one
run: |
echo "action_state=yellow" >> $GITHUB_ENV
- name: Use the value
id: step_two
run: |
echo "${{ env.action_state }}" # This will output 'yellow'
```
{% endraw %}
### Multiline strings
For multiline strings, you may use a delimiter with the following syntax.
```
{name}<<{delimiter}
{value}
{delimiter}
```
#### Example
In this example, we use `EOF` as a delimiter and set the `JSON_RESPONSE` environment variable to the value of the curl response.
```yaml
steps:
- name: Set the value
id: step_one
run: |
echo 'JSON_RESPONSE<<EOF' >> $GITHUB_ENV
curl https://httpbin.org/json >> $GITHUB_ENV
echo 'EOF' >> $GITHUB_ENV
```
## Adding a system path
``` bash
echo "{path}" >> $GITHUB_PATH
```
Prepends a directory to the system `PATH` variable and automatically makes it available to all subsequent actions in the current job; the currently running action cannot access the updated path variable. To see the currently defined paths for your job, you can use `echo "$PATH"` in a step or an action.
### Example
This example demonstrates how to add the user `$HOME/.local/bin` directory to `PATH`:
``` bash
echo "$HOME/.local/bin" >> $GITHUB_PATH
```

99
translations/ja-JP/content/actions/learn-github-actions/creating-starter-workflows-for-your-organization.md
View File

@@ -1,99 +0,0 @@
---
title: Creating starter workflows for your organization
shortTitle: Creating starter workflows
intro: Learn how you can create starter workflows to help people in your team add new workflows more easily.
redirect_from:
- /actions/configuring-and-managing-workflows/sharing-workflow-templates-within-your-organization
- /actions/learn-github-actions/creating-workflow-templates
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- Workflows
- CI
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## 概要
{% data reusables.actions.workflow-organization-templates %}
## Creating a starter workflow
Starter workflows can be created by users with write access to the organization's `.github` repository. These can then be used by organization members who have permission to create workflows.
{% ifversion fpt %}
Starter workflows created by users can only be used to create workflows in public repositories. Organizations using {% data variables.product.prodname_ghe_cloud %} can also use starter workflows to create workflows in private repositories. For more information, see the [{% data variables.product.prodname_ghe_cloud %} documentation](/enterprise-cloud@latest/actions/learn-github-actions/creating-starter-workflows-for-your-organization).
{% endif %}
{% ifversion fpt or ghes > 3.3 or ghae-issue-4757 or ghec %}
{% note %}
**Note:** To avoid duplication among starter workflows you can call reusable workflows from within a workflow. This can help make your workflows easier to maintain. For more information, see "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)."
{% endnote %}
{% endif %}
This procedure demonstrates how to create a starter workflow and metadata file. The metadata file describes how the starter workflows will be presented to users when they are creating a new workflow.
1. 存在しない場合は、Organization内で`.github`という名前の新しいパブリック リポジトリを作成します。
2. `workflow-templates`という名前のディレクトリを作成します。
3. `workflow-templates` ディレクトリ内に新しいワークフローファイルを作成します。
リポジトリのデフォルトブランチを参照する必要がある場合は、 `$default-branch` プレースホルダを使用できます。 When a workflow is created the placeholder will be automatically replaced with the name of the repository's default branch.
たとえば、`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@v2
- name: Run a one-line script
run: echo Hello from Octo Organization
```
4. `workflow-templates` ディレクトリ内にメタデータファイルを作成します。 メタデータ ファイルは、ワークフロー ファイルと同じ名前である必要がありますが、 `.yml` 拡張子の代わりに、 `.properties.json`を付ける必要があります。 たとえば`octo-organization-ci.properties.json`という名前のこのファイルには 、`octo-organization-ci.yml`という名前のワークフローファイルのメタデータが含まれています。
```yaml
{
"name": "Octo Organization Workflow",
"description": "Octo Organization CI starter workflow.",
"iconName": "example-icon",
"categories": [
"Go"
],
"filePatterns": [
"package.json$",
"^Dockerfile",
".*\\.md$"
]
}
```
* `name` - **Required.** The name of the workflow. This is displayed in the list of available workflows.
* `description` - **Required.** The description of the workflow. This is displayed in the list of available workflows.
* `iconName` - **Optional.** Specifies an icon for the workflow that's displayed in the list of workflows. The `iconName` must be the name of an SVG file, without the file name extension, stored in the `workflow-templates` directory. For example, an SVG file named `example-icon.svg` is referenced as `example-icon`.
* `categories` - **オプション。** ワークフローの言語カテゴリを定義します。 When a user views the available starter workflows for a repository, the workflows that match the identified language for the project are featured more prominently. 使用可能な言語カテゴリについては、「https://github.com/github/linguist/blob/master/lib/linguist/languages.yml」を参照してください。
* `filePatterns` - **Optional.** Allows the workflow to be used if the user's repository has a file in its root directory that matches a defined regular expression.
To add another starter workflow, add your files to the same `workflow-templates` directory. 例:
![Workflow files](/assets/images/help/images/workflow-template-files.png)
## 次のステップ
To continue learning about {% data variables.product.prodname_actions %}, see "[Using starter workflows](/actions/learn-github-actions/using-starter-workflows)."

865
translations/ja-JP/content/actions/learn-github-actions/events-that-trigger-workflows.md
View File

@@ -1,865 +0,0 @@
---
title: ワークフローをトリガーするイベント
intro: '{% data variables.product.product_name %} で特定のアクティビティが実行された時、スケジュールした時間、または {% data variables.product.product_name %} 外でイベントが発生した時にワークフローを実行できるよう設定できます。'
miniTocMaxHeadingLevel: 3
redirect_from:
- /articles/events-that-trigger-workflows
- /github/automating-your-workflow-with-github-actions/events-that-trigger-workflows
- /actions/automating-your-workflow-with-github-actions/events-that-trigger-workflows
- /actions/reference/events-that-trigger-workflows
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
shortTitle: ワークフローをトリガーするイベント
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## ワークフローイベントを設定する
`on` ワークフロー構文を使用して、1 つ以上のイベントに対して実行するようにワークフローを設定できます。 詳しい情報については、「[{% data variables.product.prodname_actions %} のワークフロー構文](/articles/workflow-syntax-for-github-actions#on)」を参照してください。
{% data reusables.github-actions.actions-on-examples %}
{% note %}
**ノート:** `GITHUB_TOKEN`を使って新しいワークフローの実行をトリガーすることはできません。 詳しい情報については「[個人アクセストークンを使った新しいワークフローのトリガー](#triggering-new-workflows-using-a-personal-access-token)」を参照してください。
{% endnote %}
ワークフローの実行がトリガーされるには、以下のステップが生じます。
1. リポジトリでイベントが発生し、結果のイベントにはコミット SHA と Git ref が関連付けられます。
2. リポジトリ内の関連づけられたコミットSHAもしくはGit refにおける `.github/workflows`ディレクトリ内でワークフローファイルが検索される。 ワークフローファイルは、コミットSHAあるいはGit refを考慮した上で存在していなければなりません。
たとえば、イベントが特定のリポジトリブランチで発生したなら、ワークフローファイルはそのブランチ上でリポジトリ内に存在しなければなりません。
1. そのコミットSHA及びGit refのワークフローファイルが調べられ、トリガーを起こしたイベントにマッチする`on:`の値を持つワークフローについて新しい実行がトリガーされる。
ワークフローの実行は、イベントをトリガーしたのと同じコミットSHA及びGit refにあるリポジトリのコード上で実行されます。 ワークフローを実行すると、{% data variables.product.product_name %} はランナー環境において `GITHUB_SHA` (コミット SHA) および `GITHUB_REF` (Git ref) 環境変数を設定します。 詳しい情報については、「[環境変数の利用](/actions/automating-your-workflow-with-github-actions/using-environment-variables)」を参照してください。
## スケジュールしたイベント
`schedule` イベントを使用すると、スケジュールされた時間にワークフローをトリガーできます。
{% data reusables.actions.schedule-delay %}
### `スケジュール`
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------ | ---------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| n/a | n/a | デフォルトブランチの直近のコミット | デフォルトブランチ | スケジュールしたワークフローを実行するよう設定したとき。 スケジュールしたワークフローは、[POSIX クーロン構文](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07)を使用します。 詳しい情報については、「[イベントでワークフローをトリガーする](/articles/configuring-a-workflow/#triggering-a-workflow-with-events)」を参照してください。 |
{% data reusables.repositories.actions-scheduled-workflow-example %}
クーロン構文では、スペースで分けられた 5 つのフィールドがあり、各フィールドは時間の単位を表わします。
```
┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
* * * * *
```
5 つのフィールドいずれにおいても、以下の演算子を使用できます:
| 演算子 | 説明 | サンプル |
| --- | ---------- | --------------------------------------------------------------- |
| * | 任意の値 | `* * * * *` 毎日、毎分実行します。 |
| , | 値リストの区切り文字 | `2,10 4,5 * * *` 毎日、午前 4 時および午前 5 時の、2 分および 10 分に実行します。 |
| - | 値の範囲 | `0 4-6 * * *` 午前 4 時、5 時、および 6 時の、0 分に実行します。 |
| / | ステップ値 | `20/15 * * * *` 20 分から 59 分までの間で、15 分おきに実行します (20 分、35 分、50 分)。 |
{% note %}
**注釈:** {% data variables.product.prodname_actions %} は、非標準的構文　(`@yearly`、`@monthly`、`@weekly`、`@daily`、`@hourly`、`@reboot`) をサポートしていません。
{% endnote %}
[crontab guru](https://crontab.guru/) を使うと、クーロン構文の生成および実行時間の確認に役立ちます。 また、クーロン構文の生成を支援するため、[crontab guru のサンプル](https://crontab.guru/examples.html)リストもあります。
ワークフロー内のクーロン構文を最後に修正したユーザには、スケジュールされたワークフローの通知が送られます。 詳しい情報については「[ワークフローの実行の通知](/actions/guides/about-continuous-integration#notifications-for-workflow-runs)」を参照してください。
## 手動イベント
ワークフローの実行を手動でトリガーできます。 リポジトリ内の特定のワークフローをトリガーするには、`workflow_dispatch` イベントを使用します。 リポジトリで複数のワークフローをトリガーし、カスタムイベントとイベントタイプを作成するには、`repository_dispatch` イベントを使用します。
### `workflow_dispatch`
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------- | ---------- | -------------------------- | --------------- |
| [workflow_dispatch](/webhooks/event-payloads/#workflow_dispatch) | n/a | `GITHUB_REF` ブランチ上の直近のコミット | ディスパッチを受信したブランチ |
カスタム定義の入力プロパティ、デフォルトの入力値、イベントに必要な入力をワークフローで直接設定できます。 ワークフローが実行されると、 `github.event.inputs` コンテキスト内の入力値にアクセスできます。 詳細については、「[コンテキスト](/actions/learn-github-actions/contexts)」を参照してください。
You can manually trigger a workflow run using the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API and from {% data variables.product.product_name %}. 詳しい情報については、「[ワークフローを手動で実行する](/actions/managing-workflow-runs/manually-running-a-workflow)」を参照してください。
{% data variables.product.prodname_dotcom %} でイベントをトリガーすると、{% data variables.product.prodname_dotcom %} で `ref` と `inputs` を直接入力できます。 詳しい情報については、「[アクションで入力と出力を使用する](/actions/learn-github-actions/finding-and-customizing-actions#using-inputs-and-outputs-with-an-action)」を参照してください。
To trigger the custom `workflow_dispatch` webhook event using the REST API, you must send a `POST` request to a {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API endpoint and provide the `ref` and any required `inputs`. 詳細については、「[ワークフローディスパッチイベントの作成](/rest/reference/actions/#create-a-workflow-dispatch-event)」REST API エンドポイントを参照してください。
#### サンプル
`workflow_dispatch`イベントを使うには、GitHub Actionsのワークフローファイル中にトリガーとして含めなければなりません。 以下の例では、手動でトリガーされた場合にのみワークフローが実行されます。
```yaml
on: workflow_dispatch
```
#### ワークフロー設定の例
この例では、 `name`と`home`の入力を定義し、`github.event.inputs.name`および`github.event.inputs.home`コンテキストを使用してそれらを出力します。 `home`が提供されなければ、デフォルト値の'The Octoverse'が出力されます。
{% raw %}
```yaml
name: Manually triggered workflow
on:
workflow_dispatch:
inputs:
name:
description: 'Person to greet'
required: true
default: 'Mona the Octocat'
home:
description: 'location'
required: false
default: 'The Octoverse'
jobs:
say_hello:
runs-on: ubuntu-latest
steps:
- run: |
echo "Hello ${{ github.event.inputs.name }}!"
echo "- in ${{ github.event.inputs.home }}!"
```
{% endraw %}
### `repository_dispatch`
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------------------- | ---------- | ----------------- | ------------ |
| [repository_dispatch](/webhooks/event-payloads/#repository_dispatch) | n/a | デフォルトブランチの直近のコミット | デフォルトブランチ |
{% data reusables.github-actions.branch-requirement %}
You can use the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API to trigger a webhook event called [`repository_dispatch`](/webhooks/event-payloads/#repository_dispatch) when you want to trigger a workflow for activity that happens outside of {% data variables.product.prodname_dotcom %}. 詳細については、「[リポジトリディスパッチ イベントの作成](/rest/reference/repos#create-a-repository-dispatch-event)」を参照してください。
To trigger the custom `repository_dispatch` webhook event, you must send a `POST` request to a {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API endpoint and provide an `event_type` name to describe the activity type. ワークフローの実行をトリガーするには、`repository_dispatch` イベントを使用するようワークフローを設定する必要もあります。
#### サンプル
デフォルトでは、すべての`event_types`がワークフローの実行をトリガーします。 特定の`event_type`の値が`repository_dispatch` webhookのペイロード内で送信された時にのみワークフローが実行されるように制限できます。 リポジトリのディスパッチイベントを生成する際に、`repository_dispatch`ペイロード内で送信されるイベントの種類を定義します。
```yaml
on:
repository_dispatch:
types: [opened, deleted]
```
{% ifversion fpt or ghes > 3.3 or ghae-issue-4757 or ghec %}
## Workflow reuse events
`workflow_call` is a keyword used as the value of `on` in a workflow, in the same way as an event. It indicates that a workflow can be called from another workflow. For more information see, "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)."
### `workflow_call`
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------- | ---------- | --------------------------- | --------------------------- |
| Same as the caller workflow | n/a | Same as the caller workflow | Same as the caller workflow |
#### サンプル
To make a workflow reusable it must include `workflow_call` as one of the values of `on`. The example below only runs the workflow when it's called from another workflow:
```yaml
on: workflow_call
```
{% endif %}
## webhook イベント
webhook イベントが {% data variables.product.product_name %} で生成されたときに実行されるようにワークフローを設定できます イベントによっては、そのイベントをトリガーするアクティビティタイプが 複数あります。 イベントをトリガーするアクティビティタイプが複数ある場合は、ワークフローの実行をトリガーするアクティビティタイプを指定できます。 詳しい情報については、「[webhook](/webhooks)」を参照してください。
すべての webhook イベントがワークフローをトリガーするわけではありません。 使用可能な webhook イベントとそのペイロードの完全なリストについては、「[webhook イベントとペイロード](/developers/webhooks-and-events/webhook-events-and-payloads)」を参照してください。
{% ifversion fpt or ghec or ghes > 3.3 or ghae-issue-4968 %}
### `branch_protection_rule`
Runs your workflow anytime the `branch_protection_rule` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the GraphQL API, see "[BranchProtectionRule]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql/reference/objects#branchprotectionrule)."
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------------- | ------------------------------------------------------ | ----------------- | ------------ |
| [`branch_protection_rule`](/webhooks/event-payloads/#branch_protection_rule) | - `created`<br/>- `edited`<br/>- `deleted` | デフォルトブランチの直近のコミット | デフォルトブランチ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a branch protection rule has been `created` or `deleted`.
```yaml
on:
branch_protection_rule:
types: [created, deleted]
```
{% endif %}
### `check_run`
`check_run` イベントが発生したときにワークフローを実行します。 {% data reusables.developer-site.multiple_activity_types %} REST API の詳細については、「[チェック実行](/rest/reference/checks#runs)」を参照してください。
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------- | ------------------------------------------------------------- | ----------------- | ------------ |
| [`check_run`](/webhooks/event-payloads/#check_run) | - `created`<br/>- `rerequested`<br/>- `completed` | デフォルトブランチの直近のコミット | デフォルトブランチ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
たとえば、チェック実行が `rerequested` または `completed` であったときにワークフローを実行できます。
```yaml
on:
check_run:
types: [rerequested, completed]
```
### `check_suite`
`check_suite` イベントが発生したときにワークフローを実行します。 {% data reusables.developer-site.multiple_activity_types %} REST API の詳細については、「[チェックスイート](/rest/reference/checks#suites)」を参照してください。
{% data reusables.github-actions.branch-requirement %}
{% note %}
**ノート:** 再帰的なワークフローを避けるために、このイベントは{% data variables.product.prodname_actions %}によってチェックスイートが生成されている場合にはワークフローをトリガーしません。
{% endnote %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------ | -------------------------------------------------------------------------- | ----------------- | ------------ |
| [`check_suite`](/webhooks/event-payloads/#check_suite) | - `completed`<br/>- `requested`<br/>- `rerequested`<br/> | デフォルトブランチの直近のコミット | デフォルトブランチ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
たとえば、チェック実行が `rerequested` または `completed` だったときにワークフローを実行する例は、次のとおりです。
```yaml
on:
check_suite:
types: [rerequested, completed]
```
### `create`
誰かがブランチまたはタグを作成し、それによって `create` イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「[リファレンスの作成](/rest/reference/git#create-a-reference)」を参照してください。
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------- | ---------- | ---------------------- | -------------- |
| [`create`](/webhooks/event-payloads/#create) | n/a | 直近でブランチまたはタグが作成されたコミット | 作成されたブランチまたはタグ |
たとえば、`create` イベントが発生したときにワークフローを実行する例は、次のとおりです。
```yaml
on:
create
```
### `delete`
誰かがブランチまたはタグを作成し、それによって `delete` イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「[リファレンスの削除](/rest/reference/git#delete-a-reference)」を参照してください。
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------- | ---------- | ----------------- | ------------ |
| [`delete`](/webhooks/event-payloads/#delete) | n/a | デフォルトブランチの直近のコミット | デフォルトブランチ |
たとえば、`delete` イベントが発生したときにワークフローを実行する例は、次のとおりです。
```yaml
on:
delete
```
### `deployment`
誰かがデプロイメントを作成し、それによって `deployment` イベントがトリガーされるときにワークフローを実行します。 コミット SHA 付きで作成されたデプロイメントには Git ref がない場合があります。 REST API の詳細については、「[デプロイメント](/rest/reference/repos#deployments)」を参照してください。
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------- | ---------- | ------------ | ---------------------------- |
| [`deployment`](/webhooks/event-payloads/#deployment) | n/a | デプロイされるコミット | デプロイされるブランチまたはタグ (コミットの場合は空) |
たとえば、`deployment` イベントが発生したときにワークフローを実行する例は、次のとおりです。
```yaml
on:
deployment
```
### `deployment_status`
サードパーティプロバイダーがデプロイメントステータスを提供し、それによって `deployment_status` イベントがトリガーされるときにワークフローを実行します。 コミット SHA 付きで作成されたデプロイメントには Git ref がない場合があります。 REST API の詳細については、「[デプロイメントステータスの作成](/rest/reference/deployments#create-a-deployment-status)」を参照してください。
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------ | ---------- | ------------ | ---------------------------- |
| [`deployment_status`](/webhooks/event-payloads/#deployment_status) | n/a | デプロイされるコミット | デプロイされるブランチまたはタグ (コミットの場合は空) |
たとえば、`deployment_status` イベントが発生したときにワークフローを実行する例は、次のとおりです。
```yaml
on:
deployment_status
```
{% note %}
**注釈:** デプロイメントステータスの状態が `inactive` に設定されている場合、webhook イベントは作成されません。
{% endnote %}
{% ifversion fpt or ghec %}
### `ディスカッション`
Runs your workflow anytime the `discussion` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the GraphQL API, see "[Discussions]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql/guides/using-the-graphql-api-for-discussions)."
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | ------------ |
| [`ディスカッション`](/webhooks/event-payloads/#discussion) | - `created`<br/>- `edited`<br/>- `deleted`<br/>- `transferred`<br/>- `pinned`<br/>- `unpinned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `locked`<br/>- `unlocked`<br/>- `category_changed`<br/> - `answered`<br/> - `unanswered` | デフォルトブランチの直近のコミット | デフォルトブランチ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a discussion has been `created`, `edited`, or `answered`.
```yaml
on:
discussion:
types: [created, edited, answered]
```
### `discussion_comment`
Runs your workflow anytime the `discussion_comment` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the GraphQL API, see "[Discussions]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql/guides/using-the-graphql-api-for-discussions)."
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- | ----------------- | ------------ |
| [`discussion_comment`](/developers/webhooks-and-events/webhook-events-and-payloads#discussion_comment) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | デフォルトブランチの直近のコミット | デフォルトブランチ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
たとえば、Issue コメントが `created` または `deleted` だったときにワークフローを実行する例は、次のとおりです。
```yaml
on:
discussion_comment:
types: [created, deleted]
```
{% endif %}
### `フォーク`
誰かがリポジトリをフォークし、それによって `deployment_status` イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「[フォークの作成](/rest/reference/repos#create-a-fork)」を参照してください。
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------- | ---------- | ----------------- | ------------ |
| [`フォーク`](/webhooks/event-payloads/#fork) | n/a | デフォルトブランチの直近のコミット | デフォルトブランチ |
たとえば、`fork` イベントが発生したときにワークフローを実行する例は、次のとおりです。
```yaml
on:
fork
```
### `gollum`
誰かが Wiki ページを作成または更新し、それによって `gollum` イベントがトリガーされるときにワークフローを実行します。
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------- | ---------- | ----------------- | ------------ |
| [`gollum`](/webhooks/event-payloads/#gollum) | n/a | デフォルトブランチの直近のコミット | デフォルトブランチ |
たとえば、`gollum` イベントが発生したときにワークフローを実行する例は、次のとおりです。
```yaml
on:
gollum
```
### `issue_comment`
`issue_comment` イベントが発生したときにワークフローを実行します。 {% data reusables.developer-site.multiple_activity_types %} REST API の詳細については、「[Issue コメント](/developers/webhooks-and-events/webhook-events-and-payloads#issue_comment)」を参照してください。
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | ----------------- | ------------ |
| [`issue_comment`](/developers/webhooks-and-events/webhook-events-and-payloads#issue_comment) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | デフォルトブランチの直近のコミット | デフォルトブランチ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
たとえば、Issue コメントが `created` または `deleted` だったときにワークフローを実行する例は、次のとおりです。
```yaml
on:
issue_comment:
types: [created, deleted]
```
`issue_comment`イベントは、IssueやPull Requestにコメントされたときに生じます。 `issue_comment`イベントがIssueで生じたのかPull Requestで生じたのかを判断するには、イベントのペイロードの`issue.pull_request`属性をチェックして、それをジョブをスキップする条件として利用できます。
たとえば、コメントイベントがPull Requestで生じたときに`pr_commented`を実行し、コメントイベントがIssueで生じたときに`issue_commented`ジョブを実行するようにできます。
{% raw %}
```yaml
on: issue_comment
jobs:
pr_commented:
# このジョブはプルリクエストコメントに対してのみ実行されます
name: PR comment
if: ${{ github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo "Comment on PR #${{ github.event.issue.number }}"
issue_commented:
# このジョブは Issue comment に対してのみ実行されます
name: Issue comment
if: ${{ !github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo "Comment on issue #${{ github.event.issue.number }}"
```
{% endraw %}
### `issues`
`Issue` イベントが発生したときにワークフローを実行します。 {% data reusables.developer-site.multiple_activity_types %} REST API の詳細については、「[Issue](/rest/reference/issues)」を参照してください。
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | ------------ |
| [`issues`](/webhooks/event-payloads/#issues) | - `opened`<br/>- `edited`<br/>- `deleted`<br/>- `transferred`<br/>- `pinned`<br/>- `unpinned`<br/>- `closed`<br/>- `reopened`<br/>- `assigned`<br/>- `unassigned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `locked`<br/>- `unlocked`<br/>- `milestoned`<br/> - `demilestoned` | デフォルトブランチの直近のコミット | デフォルトブランチ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
たとえば、Issue が `opened`、`edited`、または `milestoned` だったときにワークフローを実行する例は、次のとおりです。
```yaml
on:
issues:
types: [opened, edited, milestoned]
```
### `ラベル`
`label` イベントが発生したときにワークフローを実行します。 {% data reusables.developer-site.multiple_activity_types %} REST API の詳細については、「[ラベル](/rest/reference/issues#labels)」を参照してください。
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------- | ----------------------------------------------------------------- | ----------------- | ------------ |
| [`ラベル`](/webhooks/event-payloads/#label) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | デフォルトブランチの直近のコミット | デフォルトブランチ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
たとえば、ラベルが `created` または `deleted` だったときにワークフローを実行する例は、次のとおりです。
```yaml
on:
label:
types: [created, deleted]
```
### `マイルストーン`
`milestone` イベントが発生したときにワークフローを実行します。 {% data reusables.developer-site.multiple_activity_types %} REST API の詳細については、「[マイルストーン](/rest/reference/issues#milestones)」を参照してください。
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------- | ----------------- | ------------ |
| [`マイルストーン`](/webhooks/event-payloads/#milestone) | - `created`<br/>- `closed`<br/>- `opened`<br/>- `edited`<br/>- `deleted`<br/> | デフォルトブランチの直近のコミット | デフォルトブランチ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
たとえばマイルストーンが`opened`あるいは`deleted`になったときにワークフローを実行できます。
```yaml
on:
milestone:
types: [opened, deleted]
```
### `page_build`
誰かが {% data variables.product.product_name %} ページ対応のブランチを作成し、それによって `page_build` イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「[ページ](/rest/reference/repos#pages)」を参照してください。
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------- | ---------- | ----------------- | ------------ |
| [`page_build`](/webhooks/event-payloads/#page_build) | n/a | デフォルトブランチの直近のコミット | n/a |
たとえば、`page_build` イベントが発生したときにワークフローを実行する例は、次のとおりです。
```yaml
on:
page_build
```
### `project`
`project` イベントが発生したときにワークフローを実行します。 {% data reusables.developer-site.multiple_activity_types %} REST API の詳細については、「[プロジェクト](/rest/reference/projects)」を参照してください。
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ----------------- | ------------ |
| [`project`](/webhooks/event-payloads/#project) | - `created`<br/>- `updated`<br/>- `closed`<br/>- `reopened`<br/>- `edited`<br/>- `deleted`<br/> | デフォルトブランチの直近のコミット | デフォルトブランチ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
たとえば、プロジェクトが `created` または `deleted` だったときにワークフローを実行する例は、次のとおりです。
```yaml
on:
project:
types: [created, deleted]
```
### `project_card`
`project_card` イベントが発生したときにワークフローを実行します。 {% data reusables.developer-site.multiple_activity_types %} REST API の詳細については、「[プロジェクトカード](/rest/reference/projects#cards)」を参照してください。
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ----------------- | ------------ |
| [`project_card`](/webhooks/event-payloads/#project_card) | - `created`<br/>- `moved`<br/>- `converted` to an issue<br/>- `edited`<br/>- `deleted` | デフォルトブランチの直近のコミット | デフォルトブランチ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
たとえば、プロジェクトカードが `opened` または `deleted` だったときにワークフローを実行する例は、次のとおりです。
```yaml
on:
project_card:
types: [created, deleted]
```
### `project_column`
`project_column` イベントが発生したときにワークフローを実行します。 {% data reusables.developer-site.multiple_activity_types %} REST API の詳細については、「[プロジェクト列](/rest/reference/projects#columns)」を参照してください。
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------ | --------------------------------------------------------------------------- | ----------------- | ------------ |
| [`project_column`](/webhooks/event-payloads/#project_column) | - `created`<br/>- `updated`<br/>- `moved`<br/>- `deleted` | デフォルトブランチの直近のコミット | デフォルトブランチ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
たとえば、プロジェクト列が `created` または `deleted` だったときにワークフローを実行する例は、次のとおりです。
```yaml
on:
project_column:
types: [created, deleted]
```
### `public`
誰かがプライベートリポジトリをパブリックにし、それによって `public` イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「[リポジトリの編集](/rest/reference/repos#edit)」を参照してください。
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------- | ---------- | ----------------- | ------------ |
| [`public`](/webhooks/event-payloads/#public) | n/a | デフォルトブランチの直近のコミット | デフォルトブランチ |
たとえば、`public` イベントが発生したときにワークフローを実行する例は、次のとおりです。
```yaml
on:
public
```
### `pull_request`
`pull_request` イベントが発生したときにワークフローを実行します。 {% data reusables.developer-site.multiple_activity_types %} REST API の詳細については、「[プルリクエスト](/rest/reference/pulls)」を参照してください。
{% note %}
**ノート:**
- By default, a workflow only runs when a `pull_request`'s activity type is `opened`, `synchronize`, or `reopened`. 他のアクティビティタイプについてもワークフローをトリガーするには、`types` キーワードを使用してください。
- Workflows will not run on `pull_request` activity if the pull request has a merge conflict. The merge conflict must be resolved first.
{% endnote %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- | -------------------------------------- |
| [`pull_request`](/webhooks/event-payloads/#pull_request) | - `assigned`<br/>- `unassigned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `opened`<br/>- `edited`<br/>- `closed`<br/>- `reopened`<br/>- `synchronize`<br/>- `converted_to_draft`<br/>- `ready_for_review`<br/>- `locked`<br/>- `unlocked` <br/>- `review_requested` <br/>- `review_request_removed`{% ifversion fpt or ghes > 3.0 or ghae or ghec %} <br/>- `auto_merge_enabled` <br/>- `auto_merge_disabled`{% endif %} | `GITHUB_REF` ブランチ上の直近のマージコミット | PR マージブランチ `refs/pull/:prNumber/merge` |
デフォルトのアクティビティタイプを拡大または制限するには、`types` キーワードを使用します。 詳しい情報については、「[{% data variables.product.prodname_actions %}のワークフロー構文](/articles/workflow-syntax-for-github-actions#onevent_nametypes)」を参照してください。
たとえば、プルリクエストが `assigned`、`opened`、`synchronize`、または `reopened` だったときにワークフローを実行できます。
```yaml
on:
pull_request:
types: [assigned, opened, synchronize, reopened]
```
{% data reusables.developer-site.pull_request_forked_repos_link %}
### `pull_request_review`
`pull_request_review` イベントが発生したときにワークフローを実行します。 {% data reusables.developer-site.multiple_activity_types %} REST API の詳細については、「[プルリクエストレビュー](/rest/reference/pulls#reviews)」を参照してください。
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------- | ---------------------------------------------------------- | ----------------------------- | -------------------------------------- |
| [`pull_request_review`](/webhooks/event-payloads/#pull_request_review) | - `submitted`<br/>- `edited`<br/>- `dismissed` | `GITHUB_REF` ブランチ上の直近のマージコミット | PR マージブランチ `refs/pull/:prNumber/merge` |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
たとえば、プルリクエストレビューが `edited` または `dismissed` だったときにワークフローを実行する例は、次のとおりです。
```yaml
on:
pull_request_review:
types: [edited, dismissed]
```
{% data reusables.developer-site.pull_request_forked_repos_link %}
### `pull_request_review_comment`
プルリクエストの統合 diff へのコメントが変更され、それによって `pull_request_review_comment` イベントがトリガーされるときにワークフローを実行します。 {% data reusables.developer-site.multiple_activity_types %} REST API の詳細については、「[レビューコメント](/rest/reference/pulls#comments)」を参照してください。
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------------------------------------- | ------------------------------------------------------ | ----------------------------- | -------------------------------------- |
| [`pull_request_review_comment`](/webhooks/event-payloads/#pull_request_review_comment) | - `created`<br/>- `edited`<br/>- `deleted` | `GITHUB_REF` ブランチ上の直近のマージコミット | PR マージブランチ `refs/pull/:prNumber/merge` |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
たとえば、プルリクエストレビューコメントが `created` または `deleted` だったときにワークフローを実行する例は、次のとおりです。
```yaml
on:
pull_request_review_comment:
types: [created, deleted]
```
{% data reusables.developer-site.pull_request_forked_repos_link %}
### `pull_request_target`
このイベントは`pull_request`のようにマージコミット内ではなく、Pull Requestのベースのコンテキストで実行されます。 これにより、リポジトリを変更したり、ワークフローで使うシークレットを盗んだりするような、Pull Requestのヘッドからの安全ではないワークフローのコードが実行されるのを避けられます。 このイベントでは、イベントペイロードの内容に基づいて、プルリクエストにラベルを付けてコメントを付けるワークフローを作成するようなことができます。
{% warning %}
**警告:** `pull_request_target`イベントは、フォークからトリガーされた場合であっても、リポジトリトークンの読み書きが許可されており、シークレットにアクセスできます。 ワークフローはPull Requestのベースのコンテキストで実行されますが、このイベントでPull Requestから信頼できないコードをチェックアウトしたり、ビルドしたり、実行したりしないようにしなければなりません。 加えて、ベースブランチと同じスコープを共有するキャッシュがあり、キャッシュが汚染されることを避けるために、キャッシュの内容が変更されている可能性があるなら、キャッシュを保存するべきではありません。 詳細については、GitHub Security Lab Web サイトの「[GitHub Actions とワークフローを安全に保つ: pwn リクエストの防止](https://securitylab.github.com/research/github-actions-preventing-pwn-requests)」を参照してください。
{% endwarning %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | ------------ |
| [`pull_request_target`](/webhooks/event-payloads/#pull_request) | - `assigned`<br/>- `unassigned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `opened`<br/>- `edited`<br/>- `closed`<br/>- `reopened`<br/>- `synchronize`<br/>- `converted_to_draft`<br/>- `ready_for_review`<br/>- `locked`<br/>- `unlocked` <br/>- `review_requested` <br/>- `review_request_removed`{% ifversion fpt or ghes > 3.0 or ghae or ghec %} <br/>- `auto_merge_enabled` <br/>- `auto_merge_disabled`{% endif %} | PR ベースブランチの直近のコミット | PR ベースブランチ |
デフォルトでは、ワークフローは、`pull_request_target` のアクティビティタイプが `opened`、`synchronize`、または `reopened` のときにのみ実行されます。 他のアクティビティタイプについてもワークフローをトリガーするには、`types` キーワードを使用してください。 詳しい情報については、「[{% data variables.product.prodname_actions %}のワークフロー構文](/articles/workflow-syntax-for-github-actions#onevent_nametypes)」を参照してください。
たとえば、プルリクエストが `assigned`、`opened`、`synchronize`、または `reopened` だったときにワークフローを実行できます。
```yaml
on:
pull_request_target:
types: [assigned, opened, synchronize, reopened]
```
### `プッシュ`
{% note %}
**ノート：** GitHub Actionsが利用できるwebhookのペイロードには、`commit`オブジェクト中の`added`、`removed`、`modified`属性は含まれません。 完全なcommitオブジェクトは、REST APIを使って取得できます。 詳しい情報については、「[1つのコミットの取得](/rest/reference/commits#get-a-commit)」を参照してください。
{% endnote %}
誰かがリポジトリブランチにプッシュし、それによって `push` イベントがトリガーされるときにワークフローを実行します。
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------- | ---------- | --------------------------------------------- | ------------ |
| [`プッシュ`](/webhooks/event-payloads/#push) | n/a | プッシュされたコミット、ただし (デフォルトブランチの際に) ブランチを削除する場合を除く | 更新された ref |
たとえば、`push` イベントが発生したときにワークフローを実行する例は、次のとおりです。
```yaml
on:
push
```
### `registry_package`
パッケージが`published`もしくは`updated`されるとワークフローを実行します。 詳しい情報については「[{% data variables.product.prodname_registry %}でのパッケージ管理](/github/managing-packages-with-github-packages)」を参照してください。
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------- | ----------------------------------- | --------------- | --------------------- |
| [`registry_package`](/webhooks/event-payloads/#package) | - `published`<br/>- `updated` | 公開されたパッケージのコミット | 公開されたパッケージのブランチもしくはタグ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
たとえば、パッケージが`published`されたときにワークフローを実行できます。
```yaml
on:
registry_package:
types: [published]
```
### `リリース`
{% note %}
**注釈:** `release` イベントは、ドラフトリリースではトリガーされません。
{% endnote %}
`release` イベントが発生したときにワークフローを実行します。 {% data reusables.developer-site.multiple_activity_types %} REST API の詳細については、「[リリース](/rest/reference/repos#releases)」を参照してください。
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | ------------ |
| [`リリース`](/webhooks/event-payloads/#release) | - `published` <br/>- `unpublished` <br/>- `created` <br/>- `edited` <br/>- `deleted` <br/>- `prereleased`<br/> - `released` | リリースのタグが付いた直近のコミット | リリースのタグ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
たとえば、リリースが `published` だったときにワークフローを実行する例は、次のとおりです。
```yaml
on:
release:
types: [published]
```
{% note %}
**注釈:** `prereleased` タイプは、ドラフトリリースから公開されたプレリリースではトリガーされませんが、`published` タイプはトリガーされます。 安定版*および*プレリリースの公開時にワークフローを実行する場合は、`released` および `prereleased` ではなく `published` にサブスクライブします。
{% endnote %}
### `ステータス`
Git コミットのステータスが変更された、それによって `status` イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「[ステータス](/rest/reference/repos#statuses)」を参照してください。
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------- | ---------- | ----------------- | ------------ |
| [`ステータス`](/webhooks/event-payloads/#status) | n/a | デフォルトブランチの直近のコミット | n/a |
たとえば、`status` イベントが発生したときにワークフローを実行する例は、次のとおりです。
```yaml
on:
status
```
### `Watch`
`watch` イベントが発生したときにワークフローを実行します。 {% data reusables.developer-site.multiple_activity_types %} REST API の詳細については、「[Star を付ける](/rest/reference/activity#starring)」を参照してください。
{% data reusables.github-actions.branch-requirement %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------ | ----------- | ----------------- | ------------ |
| [`Watch`](/webhooks/event-payloads/#watch) | - `started` | デフォルトブランチの直近のコミット | デフォルトブランチ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
たとえば、誰かがリポジトリに Star を付け、それが Watch イベントをトリガーする `started` アクティブタイプである場合にワークフローを実行する例は、次のとおりです。
```yaml
on:
watch:
types: [started]
```
### `workflow_run`
{% data reusables.webhooks.workflow_run_desc %}
{% note %}
**ノート:**
* This event will only trigger a workflow run if the workflow file is on the default branch.
* You can't use `workflow_run` to chain together more than three levels of workflows. For example, if you attempt to trigger five workflows (named `B` to `F`) to run sequentially after an initial workflow `A` has run (that is: `A` → `B` → `C` → `D` → `E` → `F`), workflows `E` and `F` will not be run.
{% endnote %}
| webhook イベントのペイロード | アクティビティタイプ | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------- | ------------------------------------- | ----------------- | ------------ |
| [`workflow_run`](/webhooks/event-payloads/#workflow_run) | - `completed`<br/>- `requested` | デフォルトブランチの直近のコミット | デフォルトブランチ |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
このイベントからブランチをフィルタする必要がある場合は、`branches` または `branches-ignore` を使用できます。
この例では、ワークフローは個別の「Run Tests」ワークフローの完了後に実行されるように設定されています。
```yaml
on:
workflow_run:
workflows: ["Run Tests"]
branches: [main]
types:
- completed
- requested
```
前回のワークフロー実行の結果に基づいて条件付きでワークフロージョブを実行する場合、[`jobs.<job_id>.if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif) または [`jobs.<job_id>.steps[*].if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsif) 条件を前回の実行の `conclusion` と組み合わせて使用できます。 例:
```yaml
on:
workflow_run:
workflows: ["Build"]
types: [completed]
jobs:
on-success:
runs-on: ubuntu-latest
if: {% raw %}${{ github.event.workflow_run.conclusion == 'success' }}{% endraw %}
steps:
...
on-failure:
runs-on: ubuntu-latest
if: {% raw %}${{ github.event.workflow_run.conclusion == 'failure' }}{% endraw %}
steps:
...
```
## 個人アクセストークンを使った新しいワークフローのトリガー
{% data reusables.github-actions.actions-do-not-trigger-workflows %} 詳しい情報については「[GITHUB_TOKENでの認証](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)」を参照してください。
ワークフローの実行からワークフローをトリガーしたい場合意は、個人アクセストークンを使ってイベントをトリガーできます。 個人アクセストークンを作成し、それをシークレットとして保存する必要があります。 {% data variables.product.prodname_actions %}の利用コストを最小化するために、再帰的あるいは意図しないワークフローの実行が生じないようにしてください。 個人アクセストークンのシークレットとしての保存に関する詳しい情報については「[暗号化されたシークレットの作成と保存](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)」を参照してください。

186
translations/ja-JP/content/actions/learn-github-actions/managing-complex-workflows.md
View File

@@ -1,186 +0,0 @@
---
title: Managing complex workflows
shortTitle: Managing complex workflows
intro: 'This guide shows you how to use the advanced features of {% data variables.product.prodname_actions %}, with secret management, dependent jobs, caching, build matrices,{% ifversion fpt or ghes > 3.0 or ghae or ghec %} environments,{% endif %} and labels.'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: how_to
topics:
- Workflows
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Overview
This article describes some of the advanced features of {% data variables.product.prodname_actions %} that help you create more complex workflows.
## Storing secrets
If your workflows use sensitive data, such as passwords or certificates, you can save these in {% data variables.product.prodname_dotcom %} as _secrets_ and then use them in your workflows as environment variables. This means that you will be able to create and share workflows without having to embed sensitive values directly in the YAML workflow.
This example action demonstrates how to reference an existing secret as an environment variable, and send it as a parameter to an example command.
{% raw %}
```yaml
jobs:
example-job:
runs-on: ubuntu-latest
steps:
- name: Retrieve secret
env:
super_secret: ${{ secrets.SUPERSECRET }}
run: |
example-command "$super_secret"
```
{% endraw %}
For more information, see "[Creating and storing encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)."
## Creating dependent jobs
By default, the jobs in your workflow all run in parallel at the same time. So if you have a job that must only run after another job has completed, you can use the `needs` keyword to create this dependency. If one of the jobs fails, all dependent jobs are skipped; however, if you need the jobs to continue, you can define this using the [`if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif) conditional statement.
In this example, the `setup`, `build`, and `test` jobs run in series, with `build` and `test` being dependent on the successful completion of the job that precedes them:
```yaml
jobs:
setup:
runs-on: ubuntu-latest
steps:
- run: ./setup_server.sh
build:
needs: setup
runs-on: ubuntu-latest
steps:
- run: ./build_server.sh
test:
needs: build
runs-on: ubuntu-latest
steps:
- run: ./test_server.sh
```
For more information, see [`jobs.<job_id>.needs`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds).
## Using a build matrix
You can use a build matrix if you want your workflow to run tests across multiple combinations of operating systems, platforms, and languages. The build matrix is created using the `strategy` keyword, which receives the build options as an array. For example, this build matrix will run the job multiple times, using different versions of Node.js:
{% raw %}
```yaml
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node: [6, 8, 10]
steps:
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node }}
```
{% endraw %}
For more information, see [`jobs.<job_id>.strategy.matrix`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix).
{% ifversion fpt or ghec %}
## Caching dependencies
{% data variables.product.prodname_dotcom %}-hosted runners are started as fresh environments for each job, so if your jobs regularly reuse dependencies, you can consider caching these files to help improve performance. Once the cache is created, it is available to all workflows in the same repository.
This example demonstrates how to cache the ` ~/.npm` directory:
{% raw %}
```yaml
jobs:
example-job:
steps:
- name: Cache node modules
uses: actions/cache@v2
env:
cache-name: cache-node-modules
with:
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
```
{% endraw %}
For more information, see "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching dependencies to speed up workflows</a>."
{% endif %}
## Using databases and service containers
If your job requires a database or cache service, you can use the [`services`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idservices) keyword to create an ephemeral container to host the service; the resulting container is then available to all steps in that job and is removed when the job has completed. This example demonstrates how a job can use `services` to create a `postgres` container, and then use `node` to connect to the service.
```yaml
jobs:
container-job:
runs-on: ubuntu-latest
container: node:10.18-jessie
services:
postgres:
image: postgres
steps:
- name: Check out repository code
uses: actions/checkout@v2
- name: Install dependencies
run: npm ci
- name: Connect to PostgreSQL
run: node client.js
env:
POSTGRES_HOST: postgres
POSTGRES_PORT: 5432
```
For more information, see "[Using databases and service containers](/actions/configuring-and-managing-workflows/using-databases-and-service-containers)."
## Using labels to route workflows
This feature helps you assign jobs to a specific hosted runner. If you want to be sure that a particular type of runner will process your job, you can use labels to control where jobs are executed. You can assign labels to a self-hosted runner in addition to their default label of `self-hosted`. Then, you can refer to these labels in your YAML workflow, ensuring that the job is routed in a predictable way.{% ifversion not ghae %} {% data variables.product.prodname_dotcom %}-hosted runners have predefined labels assigned.{% endif %}
This example shows how a workflow can use labels to specify the required runner:
```yaml
jobs:
example-job:
runs-on: [self-hosted, linux, x64, gpu]
```
A workflow will only run on a runner that has all the labels in the `runs-on` array. The job will preferentially go to an idle self-hosted runner with the specified labels. If none are available and a {% data variables.product.prodname_dotcom %}-hosted runner with the specified labels exists, the job will go to a {% data variables.product.prodname_dotcom %}-hosted runner.
To learn more about self-hosted runner labels, see ["Using labels with self-hosted runners](/actions/hosting-your-own-runners/using-labels-with-self-hosted-runners)."
{% ifversion fpt or ghes %}
To learn more about {% data variables.product.prodname_dotcom %}-hosted runner labels, see ["Supported runners and hardware resources"](/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources).
{% endif %}
{% data reusables.actions.reusable-workflows %}
{% ifversion fpt or ghes > 3.0 or ghae or ghec %}
## Using environments
You can configure environments with protection rules and secrets. Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. For more information, see "[Using environments for deployment](/actions/deployment/using-environments-for-deployment)."
{% endif %}
## Using starter workflows
{% data reusables.actions.workflow-template-overview %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.actions-tab %}
1. If your repository already has existing workflows: In the upper-left corner, click **New workflow**.
![Create a new workflow](/assets/images/help/repository/actions-new-workflow.png)
1. Under the name of the starter workflow you'd like to use, click **Set up this workflow**.
![Set up this workflow](/assets/images/help/settings/actions-create-starter-workflow.png)
## Next steps
To continue learning about {% data variables.product.prodname_actions %}, see "[Sharing workflows, secrets, and runners with your organization](/actions/learn-github-actions/sharing-workflows-secrets-and-runners-with-your-organization)."

304
translations/ja-JP/content/actions/learn-github-actions/reusing-workflows.md
View File

@@ -1,304 +0,0 @@
---
title: Reusing workflows
shortTitle: Reusing workflows
intro: Learn how to avoid duplication when creating a workflow by reusing existing workflows.
miniTocMaxHeadingLevel: 3
versions:
fpt: '*'
ghec: '*'
ghes: '>=3.4'
ghae: issue-4757
type: how_to
topics:
- Workflows
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## 概要
Rather than copying and pasting from one workflow to another, you can make workflows reusable. You and anyone with access to the reusable workflow can then call the reusable workflow from another workflow.
Reusing workflows avoids duplication. This makes workflows easier to maintain and allows you to create new workflows more quickly by building on the work of others, just as you do with actions. Workflow reuse also promotes best practice by helping you to use workflows that are well designed, have already been tested, and have been proved to be effective. Your organization can build up a library of reusable workflows that can be centrally maintained.
The diagram below shows three build jobs on the left of the diagram. After each of these jobs completes successfully a dependent job called "Deploy" runs. This job calls a reusable workflow that contains three jobs: "Staging", "Review", and "Production." The "Production" deployment job only runs after the "Staging" job has completed successfully. Using a reusable workflow to run deployment jobs allows you to run those jobs for each build without duplicating code in workflows.
![Diagram of a reusable workflow for deployment](/assets/images/help/images/reusable-workflows-ci-cd.png)
A workflow that uses another workflow is referred to as a "caller" workflow. The reusable workflow is a "called" workflow. One caller workflow can use multiple called workflows. Each called workflow is referenced in a single line. The result is that the caller workflow file may contain just a few lines of YAML, but may perform a large number of tasks when it's run. When you reuse a workflow, the entire called workflow is used, just as if it was part of the caller workflow.
If you reuse a workflow from a different repository, any actions in the called workflow run as if they were part of the caller workflow. For example, if the called workflow uses `actions/checkout`, the action checks out the contents of the repository that hosts the caller workflow, not the called workflow.
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 "[Context and expression syntax for GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)."
### Reusable workflows and starter workflow
Starter workflow allow everyone in your organization who has permission to create workflows to do so more quickly and easily. When people create a new workflow, they can choose a starter workflow and some or all of the work of writing the workflow will be done for them. Inside starter workflow, you can also reference reusable workflows to make it easy for people to benefit from reusing centrally managed workflow code. If you use a tag or branch name when referencing the reusable workflow then you can ensure that everyone who reuses that workflow will always be using the same YAML code. However, if you reference a reusable workflow by a tag or branch, be sure that you can trust that version of the workflow. For more information, see "[Security hardening for {% data variables.product.prodname_actions %}](/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows)."
For more information, see "[Creating starter workflows for your organization](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)."
## Access to reusable workflows
A reusable workflow can be used by another workflow if {% ifversion ghes or ghec or ghae %}any{% else %}either{% endif %} of the following is true:
* Both workflows are in the same repository.
* The called workflow is stored in a public repository.{% ifversion ghes or ghec or ghae %}
* The called workflow is stored in an internal repository and the settings for that repository allow it to be accessed. For more information, see "[Managing {% data variables.product.prodname_actions %} settings for a repository](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository)."{% endif %}
## Using runners
{% ifversion fpt or ghes or ghec %}
### Using GitHub-hosted runners
The assignment of {% data variables.product.prodname_dotcom %}-hosted runners is always evaluated using only the caller's context. Billing for {% data variables.product.prodname_dotcom %}-hosted runners is always associated with the caller. The caller workflow cannot use {% data variables.product.prodname_dotcom %}-hosted runners from the called repository. 詳しい情報については「[{% data variables.product.prodname_dotcom %}ホストランナーについて](/actions/using-github-hosted-runners/about-github-hosted-runners)」を参照してください。
### Using self-hosted runners
{% endif %}
Called workflows can access self-hosted runners from 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{% ifversion ghes or ghec or ghae %} or enterprise{% endif %}, provided that the runner has been made available to the caller repository
## 制限事項
* Reusable workflows can't call other reusable workflows.
* Reusable workflows stored within a private repository can only be used by workflows within the same repository.
* 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 about the `env` context, see "[Context and expression syntax for GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#env-context)."
* The `strategy` property is not supported in any job that calls a reusable workflow.
## Creating a reusable workflow
Reusable workflows are YAML-formatted files, very similar to any other workflow file. As with other workflow files, you locate reusable workflows in the `.github/workflows` directory of a repository. Subdirectories of the `workflows` directory are not supported.
For a workflow to be reusable, the values for `on` must include `workflow_call`:
```yaml
on:
workflow_call:
```
### Using inputs and secrets in a reusable workflow
You can define inputs and secrets, which can be passed from the caller workflow and then used within the called workflow. There are three stages to using an input or a secret in a reusable workflow.
1. In the reusable workflow, use the `inputs` and `secrets` keywords to define inputs or secrets that will be passed from a caller workflow.
{% raw %}
```yaml
on:
workflow_call:
inputs:
username:
required: true
type: string
secrets:
envPAT:
required: true
```
{% endraw %}
For details of the syntax for defining inputs and secrets, see [`on.workflow_call.inputs`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callinputs) and [`on.workflow_call.secrets`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callsecrets).
1. Reference the input or secret in the reusable workflow.
{% raw %}
```yaml
jobs:
reusable_workflow_job:
runs-on: ubuntu-latest
environment: production
steps:
- uses: ./.github/actions/my-action@v1
with:
username: ${{ inputs.username }}
token: ${{ secrets.envPAT }}
```
{% endraw %}
In the example above, `envPAT` is an environment secret that's been added to the `production` environment. This environment is therefore referenced within the job.
{% note %}
**Note**: Environment secrets are encrypted strings that are stored in an environment that you've defined for a repository. Environment secrets are only available to workflow jobs that reference the appropriate environment. For more information, see "[Using environments for deployment](/actions/deployment/targeting-different-environments/using-environments-for-deployment#environment-secrets)."
{% endnote %}
1. Pass the input or secret from the caller workflow.
{% indented_data_reference reusables.actions.pass-inputs-to-reusable-workflows spaces=3 %}
### Example reusable workflow
This reusable workflow file named `workflow-B.yml` (we'll refer to this later in the [example caller workflow](#example-caller-workflow)) takes an input string and a secret from the caller workflow and uses them in an action.
{% raw %}
```yaml{:copy}
name: Reusable workflow example
on:
workflow_call:
inputs:
username:
required: true
type: string
secrets:
token:
required: true
jobs:
example_job:
name: Pass input and secrets to my-action
runs-on: ubuntu-latest
steps:
- uses: ./.github/actions/my-action@v1
with:
username: ${{ inputs.username }}
token: ${{ secrets.token }}
```
{% endraw %}
## Calling a reusable workflow
You call a reusable workflow by using the `uses` keyword. Unlike when you are using actions within a workflow, you call reusable workflows directly within a job, and not from within job steps.
[`jobs.<job_id>.uses`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_iduses)
You reference reusable workflow files using the syntax:
`{owner}/{repo}/{path}/{filename}@{ref}`
You can call multiple workflows, referencing each in a separate job.
{% data reusables.actions.uses-keyword-example %}
### Passing inputs and secrets to a reusable workflow
{% data reusables.actions.pass-inputs-to-reusable-workflows%}
### 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:
* [`jobs.<job_id>.name`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idname)
* [`jobs.<job_id>.uses`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_iduses)
* [`jobs.<job_id>.with`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idwith)
* [`jobs.<job_id>.with.<input_id>`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idwithinput_id)
* [`jobs.<job_id>.secrets`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsecrets)
* [`jobs.<job_id>.secrets.<secret_id>`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsecretssecret_id)
* [`jobs.<job_id>.needs`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)
* [`jobs.<job_id>.if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif)
* [`jobs.<job_id>.permissions`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idpermissions)
{% 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`. 詳しい情報については、「[ワークフローでの認証](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)」を参照してください。
* The `GITHUB_TOKEN` permissions passed from the caller workflow can be only downgraded (not elevated) by the called workflow.
{% endnote %}
### Example caller workflow
This workflow file calls two workflow files. The second of these, `workflow-B.yml` (shown in the [example reusable workflow](#example-reusable-workflow)), is passed an input (`username`) and a secret (`token`).
{% raw %}
```yaml{:copy}
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:
uses: octo-org/example-repo/.github/workflows/workflow-B.yml@main
with:
username: mona
secrets:
token: ${{ secrets.TOKEN }}
```
{% endraw %}
## Using outputs from a reusable workflow
A reusable workflow may generate data that you want to use in the caller workflow. To use these outputs, you must specify them as the outputs of the reusable workflow.
The following reusable workflow has a single job containing two steps. In each of these steps we set a single word as the output: "hello" and "world." In the `outputs` section of the job, we map these step outputs to job outputs called: `output1` and `output2`. In the `on.workflow_call.outputs` section we then define two outputs for the workflow itself, one called `firstword` which we map to `output1`, and one called `secondword` which we map to `output2`.
{% raw %}
```yaml{:copy}
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 "::set-output name=firstword::hello"
- id: step2
run: echo "::set-output name=secondword::world"
```
{% endraw %}
We can now use the outputs in the caller workflow, in the same way you would use the outputs from a job within the same workflow. We reference the outputs using the names defined at the workflow level in the reusable workflow: `firstword` and `secondword`. In this workflow, `job1` calls the reusable workflow and `job2` prints the outputs from the reusable workflow ("hello world") to standard output in the workflow log.
{% raw %}
```yaml{:copy}
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 }}
```
{% endraw %}
For more information on using job outputs, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idoutputs)."
## Monitoring which workflows are being used
You can use the {% data variables.product.prodname_dotcom %} REST API to monitor how reusable workflows are being used. The `prepared_workflow_job` audit log action is triggered when a workflow job is started. Included in the data recorded are:
* `repo` - the organization/repository where the workflow job is located. For a job that calls another workflow, this is the organization/repository of the caller workflow.
* `@timestamp` - the date and time that the job was started, in Unix epoch format.
* `job_name` - the name of the job that was run.
* `job_workflow_ref` - the workflow file that was used, in the form `{owner}/{repo}/{path}/{filename}@{ref}`. For a job that calls another workflow, this identifies the called workflow.
For information about using the REST API to query the audit log for an organization, see "[Organizations](/rest/reference/orgs#get-the-audit-log-for-an-organization)."
{% note %}
**Note**: Audit data for `prepared_workflow_job` can only be viewed using the REST API. It is not visible in the {% data variables.product.prodname_dotcom %} web interface, or included in JSON/CSV exported audit data.
{% endnote %}
## 次のステップ
To continue learning about {% data variables.product.prodname_actions %}, see "[Events that trigger workflows](/actions/learn-github-actions/events-that-trigger-workflows)."

54
translations/ja-JP/content/actions/learn-github-actions/sharing-workflows-secrets-and-runners-with-your-organization.md
View File

@@ -1,54 +0,0 @@
---
title: 'Sharing workflows, secrets, and runners with your organization'
shortTitle: ワークフローを Organization と共有する
intro: 'Learn how you can use organization features to collaborate with your team, by sharing starter workflow, secrets, and self-hosted runners.'
redirect_from:
- /actions/learn-github-actions/sharing-workflows-with-your-organization
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: how_to
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## 概要
ワークフローやその他の {% data variables.product.prodname_actions %} 機能を Team と共有する必要がある場合は、{% data variables.product.prodname_dotcom %} Organization 内でのコラボレーションを検討します。 Organization を使用すると、シークレット、成果物、およびセルフホストランナーを一元的に保存および管理できます。 You can also create starter workflow in the `.github` repository and share them with other users in your organization.
## Using starter workflows
{% data reusables.actions.workflow-organization-templates %} For more information, see "[Creating starter workflows for your organization](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)."
{% data reusables.actions.reusable-workflows %}
## Organization 内でシークレットを共有する
Organization 内でシークレットを一元管理し、選択したリポジトリで使用できるようにすることができます。 これは、1 つの場所でシークレットを更新し、その変更をシークレットを使用するすべてのリポジトリワークフローに適用できるということを示します。
Organizationでシークレットを作成する場合、ポリシーを使用して、そのシークレットにアクセスできるリポジトリを制限できます。 たとえば、すべてのリポジトリにアクセスを許可したり、プライベート リポジトリまたは指定したリポジトリ のリストのみにアクセスを制限したりできます。
{% data reusables.github-actions.permissions-statement-secrets-organization %}
{% data reusables.organizations.navigate-to-org %}
{% data reusables.organizations.org_settings %}
{% data reusables.github-actions.sidebar-secret %}
1. [**New secret（新しいシークレット）**] をクリックします。
1. **[Name（名前）]** 入力ボックスにシークレットの名前を入力します。
1. シークレットの **Value（値）** を入力します。
1. [ **Repository access（リポジトリアクセス）** ドロップダウン リストから、アクセス ポリシーを選択します。
1. [**Add secret（シークレットの追加）**] をクリックします。
## Organization 内でセルフホストランナーを共有する
Organization の管理者は、セルフホストランナーをグループに追加してから、グループにアクセスできるリポジトリを制御するポリシーを作成できます。
詳しい情報については、「[グループを使用したセルフホストランナーへのアクセスを管理する](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups)」を参照してください。
## 次のステップ
To continue learning about {% data variables.product.prodname_actions %}, see "[Creating starter workflows for your organization](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)."

54
translations/ja-JP/content/actions/learn-github-actions/using-starter-workflows.md
View File

@@ -1,54 +0,0 @@
---
title: Using starter workflows
intro: '{% data variables.product.product_name %} provides starter workflows for a variety of languages and tooling.'
redirect_from:
- /articles/setting-up-continuous-integration-using-github-actions
- /github/automating-your-workflow-with-github-actions/setting-up-continuous-integration-using-github-actions
- /actions/automating-your-workflow-with-github-actions/setting-up-continuous-integration-using-github-actions
- /actions/building-and-testing-code-with-continuous-integration/setting-up-continuous-integration-using-github-actions
- /actions/guides/setting-up-continuous-integration-using-workflow-templates
- /actions/learn-github-actions/using-workflow-templates
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- Workflows
- CI
- CD
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## About starter workflows
{% data variables.product.product_name %} offers starter workflows for a variety of languages and tooling. When you set up workflows in your repository, {% data variables.product.product_name %} analyzes the code in your repository and recommends workflows based on the language and framework in your repository. For example, if you use [Node.js](https://nodejs.org/en/), {% data variables.product.product_name %} will suggest a starter workflow file that installs your Node.js packages and runs your tests.{% if actions-starter-template-ui %} You can search and filter to find relevant starter workflows.{% endif %}
You can also create your own starter workflow to share with your organization. These starter workflows will appear alongside the {% data variables.product.product_name %}-provided starter workflows. For more information, see "[Creating starter workflows for your organization](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)."
## Using starter workflows
Anyone with write permission to a repository can set up {% data variables.product.prodname_actions %} starter workflows for CI/CD or other automation.
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.actions-tab %}
1. If you already have a workflow in your repository, click **New workflow**.
1. Find the starter workflow that you want to use, then click **Set up this workflow**.{% if actions-starter-template-ui %} To help you find the starter workflow that you want, you can search for keywords or filter by category.{% endif %}
1. If the starter workflow contains comments detailing additional setup steps, follow these steps. Many of the starter workflow have corresponding guides. For more information, see [the {% data variables.product.prodname_actions %} guides](/actions/guides)."
1. Some starter workflows use secrets. For example, {% raw %}`${{ secrets.npm_token }}`{% endraw %}. If the starter workflow uses a secret, store the value described in the secret name as a secret in your repository. For more information, see "[Encrypted secrets](/actions/reference/encrypted-secrets)."
1. Optionally, make additional changes. For example, you might want to change the value of `on` to change when the workflow runs.
1. [**Start commit**] をクリックします。
1. Write a commit message and decide whether to commit directly to the default branch or to open a pull request.
## 参考リンク
- [継続的インテグレーションについて](/articles/about-continuous-integration)
- "[Managing workflow runs](/actions/managing-workflow-runs)"
- "[About monitoring and troubleshooting](/actions/monitoring-and-troubleshooting-workflows/about-monitoring-and-troubleshooting)"
- 「[{% data variables.product.prodname_actions %} を学ぶ](/actions/learn-github-actions)」
{% ifversion fpt or ghec %}
- 「[{% data variables.product.prodname_actions %} の支払いを管理する](/billing/managing-billing-for-github-actions)」
{% endif %}

413
translations/ja-JP/content/actions/learn-github-actions/workflow-commands-for-github-actions.md
View File

@@ -1,413 +0,0 @@
---
title: GitHub Actionsのワークフローコマンド
shortTitle: ワークフロー コマンド
intro: ワークフロー内あるいはアクションのコード内でシェルコマンドを実行する際には、ワークフローコマンドを利用できます。
redirect_from:
- /articles/development-tools-for-github-actions
- /github/automating-your-workflow-with-github-actions/development-tools-for-github-actions
- /actions/automating-your-workflow-with-github-actions/development-tools-for-github-actions
- /actions/reference/development-tools-for-github-actions
- /actions/reference/logging-commands-for-github-actions
- /actions/reference/workflow-commands-for-github-actions
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## ワークフローコマンドについて
アクションは、 環境変数を設定する、他のアクションに利用される値を出力する、デバッグメッセージを出力ログに追加するなどのタスクを行うため、ランナーマシンとやりとりできます。
ほとんどのワークフローコマンドは特定の形式で `echo` コマンドを使用しますが、他のワークフローコマンドはファイルへの書き込みによって呼び出されます。 詳しい情報については、「[環境ファイル](#environment-files)」を参照してください。
``` bash
echo "::workflow-command parameter1={data},parameter2={data}::{command value}"
```
{% note %}
**ノート:** ワークフローコマンドおよびパラメータ名では、大文字と小文字は区別されません。
{% endnote %}
{% warning %}
**警告：** コマンドプロンプトを使っているなら、ワークフローコマンドを使う際にダブルクォート文字（`"`）は省いてください。
{% endwarning %}
## ワークフローコマンドを使ったツールキット関数へのアクセス
[actions/toolkit](https://github.com/actions/toolkit)には、ワークフローコマンドとして実行できる多くの関数があります。 `::`構文を使って、YAMLファイル内でワークフローコマンドを実行してください。それらのコマンドは`stdout`を通じてランナーに送信されます。 たとえば、コードを使用して出力を設定する代わりに、以下のようにします。
```javascript
core.setOutput('SELECTED_COLOR', 'green');
```
ワークフローで `set-output` コマンドを使用して、同じ値を設定できます。
{% raw %}
``` yaml
- name: Set selected color
run: echo '::set-output name=SELECTED_COLOR::green'
id: random-color-generator
- name: Get color
run: echo "The selected color is ${{ steps.random-color-generator.outputs.SELECTED_COLOR }}"
```
{% endraw %}
以下の表は、ワークフロー内で使えるツールキット関数を示しています。
| ツールキット関数 | 等価なワークフローのコマンド |
| --------------------- | --------------------------------------------------------------------- |
| `core.addPath` | Accessible using environment file `GITHUB_PATH` |
| `core.debug` | `debug` |{% ifversion fpt or ghes > 3.2 or ghae-issue-4929 or ghec %}
| `core.notice` | `notice`
{% endif %}
| `core.error` | `error` |
| `core.endGroup` | `endgroup` |
| `core.exportVariable` | Accessible using environment file `GITHUB_ENV` |
| `core.getInput` | 環境変数の`INPUT_{NAME}`を使ってアクセス可能 |
| `core.getState` | 環境変数の`STATE_{NAME}`を使ってアクセス可能 |
| `core.isDebug` | 環境変数の`RUNNER_DEBUG`を使ってアクセス可能 |
| `core.saveState` | `save-state` |
| `core.setCommandEcho` | `echo` |
| `core.setFailed` | `::error`及び`exit 1`のショートカットとして使われる |
| `core.setOutput` | `set-output` |
| `core.setSecret` | `add-mask` |
| `core.startGroup` | `group` |
| `core.warning` | `warning` |
## 出力パラメータの設定
```
::set-output name={name}::{value}
```
アクションの出力パラメータを設定します。
あるいは、出力パラメータをアクションのメタデータファイル中で宣言することもできます。 詳しい情報については、「[{% data variables.product.prodname_actions %} のメタデータ構文](/articles/metadata-syntax-for-github-actions#outputs)」を参照してください。
### サンプル
``` bash
echo "::set-output name=action_fruit::strawberry"
```
## デバッグメッセージの設定
```
::debug::{message}
```
デバッグメッセージをログに出力します。 ログでこのコマンドにより設定されたデバッグメッセージを表示するには、`ACTIONS_STEP_DEBUG` という名前のシークレットを作成し、値を `true` に設定する必要があります。 詳しい情報については、「[デバッグログの有効化](/actions/managing-workflow-runs/enabling-debug-logging)」を参照してください。
### サンプル
``` bash
echo "::debug::Set the Octocat variable"
```
{% ifversion fpt or ghes > 3.2 or ghae-issue-4929 or ghec %}
## Setting a notice message
```
::notice file={name},line={line},endLine={endLine},title={title}::{message}
```
Creates a notice message and prints the message to the log. {% data reusables.actions.message-annotation-explanation %}
{% data reusables.actions.message-parameters %}
### サンプル
``` bash
echo "::notice file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
```
{% endif %}
## 警告メッセージの設定
```
::warning file={name},line={line},endLine={endLine},title={title}::{message}
```
警告メッセージを作成し、ログにそのメッセージを出力します。 {% data reusables.actions.message-annotation-explanation %}
{% data reusables.actions.message-parameters %}
### サンプル
``` bash
echo "::warning file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
```
## エラーメッセージの設定
```
::error file={name},line={line},endLine={endLine},title={title}::{message}
```
エラーメッセージを作成し、ログにそのメッセージを出力します。 {% data reusables.actions.message-annotation-explanation %}
{% data reusables.actions.message-parameters %}
### サンプル
``` bash
echo "::error file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
```
## ログの行のグループ化
```
::group::{title}
::endgroup::
```
展開可能なグループをログ中に作成します。 グループを作成するには、`group`コマンドを使って`title`を指定してください。 `group`と`endgroup`コマンド間でログに出力したすべての内容は、ログ中の展開可能なエントリ内にネストされます。
### サンプル
```bash
echo "::group::My title"
echo "Inside group"
echo "::endgroup::"
```
![ワークフローの実行ログ中の折りたたみ可能なグループ](/assets/images/actions-log-group.png)
## ログ中での値のマスク
```
::add-mask::{value}
```
値をマスクすることにより、文字列または値がログに出力されることを防ぎます。 空白で分離された、マスクされた各語は "`*`" という文字で置き換えられます。 マスクの `value` には、環境変数または文字列を持ちいることができます。
### 文字列をマスクするサンプル
ログに `"Mona The Octocat"` を出力すると、`"***"` が表示されます。
```bash
echo "::add-mask::Mona The Octocat"
```
### 環境変数をマスクするサンプル
変数 `MY_NAME` または値 `"Mona The Octocat"` をログに出力すると。`"Mona The Octocat"` の代わりに `"***"` が表示されます。
```bash
MY_NAME="Mona The Octocat"
echo "::add-mask::$MY_NAME"
```
## ワークフローコマンドの停止と開始
`::stop-commands::{endtoken}`
ワークフローコマンドの処理を停止します。 この特殊コマンドを使うと、意図せずワークフローコマンドを実行することなくいかなるログも取れます。 たとえば、コメントがあるスクリプト全体を出力するためにログ取得を停止できます。
To stop the processing of workflow commands, pass a unique token to `stop-commands`. To resume processing workflow commands, pass the same token that you used to stop workflow commands.
{% warning %}
**Warning:** Make sure the token you're using is randomly generated and unique for each run. As demonstrated in the example below, you can generate a unique hash of your `github.token` for each run.
{% endwarning %}
```
::{endtoken}::
```
### Example stopping and starting workflow commands
{% raw %}
```yaml
jobs:
workflow-command-job:
runs-on: ubuntu-latest
steps:
- name: disable workflow commands
run: |
echo '::warning:: this is a warning'
echo "::stop-commands::`echo -n ${{ github.token }} | sha256sum | head -c 64`"
echo '::warning:: this will NOT be a warning'
echo "::`echo -n ${{ github.token }} | sha256sum | head -c 64`::"
echo '::warning:: this is a warning again'
```
{% endraw %}
## Echoing command outputs
```
::echo::on
::echo::off
```
Enables or disables echoing of workflow commands. For example, if you use the `set-output` command in a workflow, it sets an output parameter but the workflow run's log does not show the command itself. If you enable command echoing, then the log shows the command, such as `::set-output name={name}::{value}`.
Command echoing is disabled by default. However, a workflow command is echoed if there are any errors processing the command.
The `add-mask`, `debug`, `warning`, and `error` commands do not support echoing because their outputs are already echoed to the log.
You can also enable command echoing globally by turning on step debug logging using the `ACTIONS_STEP_DEBUG` secret. For more information, see "[Enabling debug logging](/actions/managing-workflow-runs/enabling-debug-logging)". In contrast, the `echo` workflow command lets you enable command echoing at a more granular level, rather than enabling it for every workflow in a repository.
### Example toggling command echoing
```yaml
jobs:
workflow-command-job:
runs-on: ubuntu-latest
steps:
- name: toggle workflow command echoing
run: |
echo '::set-output name=action_echo::disabled'
echo '::echo::on'
echo '::set-output name=action_echo::enabled'
echo '::echo::off'
echo '::set-output name=action_echo::disabled'
```
The step above prints the following lines to the log:
```
::set-output name=action_echo::enabled
::echo::off
```
Only the second `set-output` and `echo` workflow commands are included in the log because command echoing was only enabled when they were run. Even though it is not always echoed, the output parameter is set in all cases.
## pre及びpostアクションへの値の送信
`save-state`コマンドを使って、ワークフローの`pre:`あるいは`post:`アクションと共有するための環境変数を作成できます。 たとえば、`pre:`アクションでファイルを作成し、そのファイルの場所を`main:`アクションに渡し、`post:`アクションを使ってそのファイルを削除できます。 あるいは、ファイルを`main:`アクションで作成し、そのファイルの場所を`post:`アクションに渡し、`post:`アクションを使ってそのファイルを削除することもできます。
複数の`pre:`あるいは`post:`アクションがある場合、保存された値にアクセスできるのは`save-state`が使われたアクションの中でのみです。 `post:`アクションに関する詳しい情報については「[{% data variables.product.prodname_actions %}のためのメタデータ構文](/actions/creating-actions/metadata-syntax-for-github-actions#post)」を参照してください。
`save-state`コマンドはアクション内でしか実行できず、YAMLファイルでは利用できません。 保存された値は、`STATE_`プレフィックス付きで環境変数として保存されます。
以下の例はJavaScriptを使って`save-state`コマンドを実行します。 結果の環境変数は`STATE_processID`という名前になり、`12345`という値を持ちます。
``` javascript
console.log('::save-state name=processID::12345')
```
そして、`STATE_processID`変数は`main`アクションの下で実行されるクリーンアップスクリプトからのみ利用できます。 以下の例は`main`を実行し、JavaScriptを使って環境変数`STATE_processID`に割り当てられた値を表示します。
``` javascript
console.log("The running PID from the main action is: " + process.env.STATE_processID);
```
## 環境ファイル
ワークフローの実行中に、ランナーは特定のアクションを実行する際に使用できる一時ファイルを生成します。 これらのファイルへのパスは、環境変数を介して公開されます。 コマンドを適切に処理するには、これらのファイルに書き込むときに UTF-8 エンコーディングを使用する必要があります。 複数のコマンドを、改行で区切って同じファイルに書き込むことができます。
{% warning %}
**Warning:** On Windows, legacy PowerShell (`shell: powershell`) does not use UTF-8 by default. 正しいエンコーディングを使用してファイルを書き込むようにしてください。 たとえば、パスを設定するときに UTF-8 エンコーディングを設定する必要があります。
```yaml
jobs:
legacy-powershell-example:
uses: windows-2019
steps:
- shell: powershell
run: echo "mypath" | Out-File -FilePath $env:GITHUB_PATH -Encoding utf8 -Append
```
Or switch to PowerShell Core, which defaults to UTF-8:
```yaml
jobs:
modern-pwsh-example:
uses: windows-2019
steps:
- shell: pwsh
run: echo "mypath" | Out-File -FilePath $env:GITHUB_PATH -Append # no need for -Encoding utf8
```
More detail about UTF-8 and PowerShell Core found on this great [Stack Overflow answer](https://stackoverflow.com/a/40098904/162694):
> ### Optional reading: The cross-platform perspective: PowerShell _Core_:
>
> [PowerShell is now cross-platform](https://blogs.msdn.microsoft.com/powershell/2016/08/18/powershell-on-linux-and-open-source-2/), via its **[PowerShell _Core_](https://github.com/PowerShell/PowerShell)** edition, whose encoding - sensibly - ***defaults to ***BOM-less UTF-8******, in line with Unix-like platforms.
{% endwarning %}
## 環境変数の設定
``` bash
echo "{name}={value}" >> $GITHUB_ENV
```
Creates or updates an environment variable for any steps running next in a job. The step that creates or updates the environment variable does not have access to the new value, but all subsequent steps in a job will have access. 環境変数では、大文字と小文字が区別され、句読点を含めることができます。
{% note %}
**Note:** Environment variables must be explicitly referenced using the [`env` context](/actions/reference/context-and-expression-syntax-for-github-actions#env-context) in expression syntax or through use of the `$GITHUB_ENV` file directly; environment variables are not implicitly available in shell commands.
{% endnote %}
### サンプル
{% raw %}
```
steps:
- name: Set the value
id: step_one
run: |
echo "action_state=yellow" >> $GITHUB_ENV
- name: Use the value
id: step_two
run: |
echo "${{ env.action_state }}" # This will output 'yellow'
```
{% endraw %}
### 複数行の文字列
複数行の文字列の場合、次の構文で区切り文字を使用できます。
```
{name}<<{delimiter}
{value}
{delimiter}
```
#### サンプル
この例では、区切り文字として `EOF` を使用し、`JSON_RESPONSE` 環境変数を cURL レスポンスの値に設定します。
```yaml
steps:
- name: Set the value
id: step_one
run: |
echo 'JSON_RESPONSE<<EOF' >> $GITHUB_ENV
curl https://httpbin.org/json >> $GITHUB_ENV
echo 'EOF' >> $GITHUB_ENV
```
## システムパスの追加
``` bash
echo "{path}" >> $GITHUB_PATH
```
Prepends a directory to the system `PATH` variable and automatically makes it available to all subsequent actions in the current job; the currently running action cannot access the updated path variable. ジョブに現在定義されているパスを見るには、ステップもしくはアクション中で`echo "$PATH"`を使うことができます。
### サンプル
この例は、ユーザの`$HOME/.local/bin`ディレクトリを`PATH`に追加する方法を示しています。
``` bash
echo "$HOME/.local/bin" >> $GITHUB_PATH
```

1579
translations/ja-JP/content/actions/learn-github-actions/workflow-syntax-for-github-actions.md
View File

File diff suppressed because it is too large Load Diff

99
translations/pt-BR/content/actions/learn-github-actions/creating-starter-workflows-for-your-organization.md
View File

@@ -1,99 +0,0 @@
---
title: Criando fluxos de trabalho iniciais para sua organização
shortTitle: Criando fluxos de trabalho iniciais
intro: Aprenda como criar fluxos de trabalho iniciais para ajudar as pessoas na sua equipe a adicionar novos fluxos de trabalho de forma mais fácil.
redirect_from:
- /actions/configuring-and-managing-workflows/sharing-workflow-templates-within-your-organization
- /actions/learn-github-actions/creating-workflow-templates
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- Workflows
- CI
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Visão Geral
{% data reusables.actions.workflow-organization-templates %}
## Criando um fluxo de trabalho inicial
Os fluxos de trabalho iniciantes podem ser criados pelos usuários com acesso de gravação ao repositório `.github` da organização. Eles poderão ser usados pelos integrantes da organização com permissão para criar fluxos de trabalho.
{% ifversion fpt %}
Os fluxos de trabalho iniciantes criados por usuários só podem ser usados para criar fluxos de trabalho em repositórios públicos. As organizações que usam {% data variables.product.prodname_ghe_cloud %} também podem usar fluxos de trabalho iniciais para criar fluxos de trabalho em repositórios privados. Para obter mais informações, consulte a [documentação de {% data variables.product.prodname_ghe_cloud %}](/enterprise-cloud@latest/actions/learn-github-actions/creating-starter-workflows-for-your-organization).
{% endif %}
{% ifversion fpt or ghes > 3.3 or ghae-issue-4757 or ghec %}
{% note %}
**Observação:** Para evitar duplicação entre os fluxos de trabalho iniciais você pode chamar fluxos de trabalho reutilizáveis de dentro de um fluxo de trabalho. Isso pode ajudar a manter seus fluxos de trabalho de forma mais fácil. Para obter mais informações, consulte "[Reutilizando fluxos de trabalho](/actions/learn-github-actions/reusing-workflows)".
{% endnote %}
{% endif %}
Este procedimento demonstra como criar um arquivo de metadados e fluxo de trabalho inicial. O arquivo de metadados descreve como os fluxos de trabalho iniciais serão apresentados aos usuários quando estiverem criando um novo fluxo de trabalho.
1. Se já não existir, crie um novo repositório público denominado `.github` na sua organização.
2. Crie um diretório denominado `workflow-templates`.
3. Crie seu novo arquivo de fluxo de trabalho dentro do diretório `workflow-templates`.
Se você precisar referir-se ao branch-padrão de um repositório, você poderá usar o espaço reservado `branch$default`. Quando um fluxo de trabalho é criado, o espaço reservado será automaticamente substituído pelo nome do branch padrão do repositório.
Por exemplo, este arquivo denominado `octo-organization-ci.yml` demonstra um fluxo de trabalho básico.
```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@v2
- name: Run a one-line script
run: echo Hello from Octo Organization
```
4. Crie um arquivo de metadados dentro do diretório `workflow-templates`. O arquivo de metadados deve ter o mesmo nome do arquivo de fluxo de trabalho, mas em vez da extensão `.yml`, deve-se adicionar `.properties.json`. Por exemplo, este arquivo denominado `octo-organization-ci.properties.json` contém os metadados para um arquivo de fluxo de trabalho denominado `octo-organization-ci.yml`:
```yaml
{
"name": "Octo Organization Workflow",
"description": "Octo Organization CI starter workflow.",
"iconName": "example-icon",
"categories": [
"Go"
],
"filePatterns": [
"package.json$",
"^Dockerfile",
".*\\.md$"
]
}
```
* `name` - **Obrigatório.** O nome do fluxo de trabalho. É exibido na lista de fluxos de trabalho disponíveis.
* `description` - **Obrigatório.** A descrição do fluxo de trabalho. É exibido na lista de fluxos de trabalho disponíveis.
* `iconName` - **Opcional.** Especifica um íncone para o fluxo de trabalho exibido na lista de fluxos de trabalho. O `iconName` deve ser o nome de um arquivo SVG, sem a extensão de nome do arquivo, armazenado no diretório `workflow-templates`. Por exemplo, um arquivo SVG denominado `exemplo-icon.svg` é referenciado como `example-icon`.
* `categorias` - **Opcional.** Define a categoria de idioma do fluxo de trabalho. Quando um usuário visualiza os fluxos de trabalho iniciais disponíveis para um repositório, os fluxos de trabalho que correspondem à linguagem identificada para o projeto são apresentados de forma mais proeminente. Para obter informações sobre as categorias de idioma disponíveis, consulte https://github.com/github/linguist/blob/master/lib/linguist/languages.yml.
* `filePatterns` - **Opcional.** Permite que o fluxo de trabalho seja usado se o repositório do usuário tiver um arquivo no diretório-raiz que corresponde a uma expressão regular definida.
Para adicionar outro fluxo de trabalho inicial, adicione seus arquivos ao mesmo diretório `workflow-templates`. Por exemplo:
![Arquivos de fluxo de trabalho](/assets/images/help/images/workflow-template-files.png)
## Próximas etapas
Para continuar aprendendo sobre {% data variables.product.prodname_actions %}, consulte "[Usando fluxos de trabalho iniciais](/actions/learn-github-actions/using-starter-workflows)."

1585
translations/pt-BR/content/actions/learn-github-actions/events-that-trigger-workflows.md
View File

File diff suppressed because it is too large Load Diff

304
translations/pt-BR/content/actions/learn-github-actions/reusing-workflows.md
View File

@@ -1,304 +0,0 @@
---
title: Reutilizando fluxos de trabalho
shortTitle: Reutilizando fluxos de trabalho
intro: Aprenda a evitar a duplicação ao criar um fluxo de trabalho reutilizando os fluxos de trabalho existentes.
miniTocMaxHeadingLevel: 3
versions:
fpt: '*'
ghec: '*'
ghes: '>=3.4'
ghae: issue-4757
type: how_to
topics:
- Workflows
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Visão Geral
Em vez de copiar e colar de um fluxo de trabalho para outro, você pode tornar os fluxos de trabalho reutilizáveis. Você e qualquer pessoa com acesso ao fluxo de trabalho reutilizável pode chamar o fluxo de trabalho reutilizável a partir de outro fluxo de trabalho.
A reutilização dosfluxos de trabalho evita duplicação. Isso torna os fluxos de trabalho mais fáceis de manter e permite que você crie novos fluxos de trabalho mais rapidamente, desenvolvendo sobre o trabalho dos outros, assim como você faz com ações. A reutilização do fluxo de trabalho também promove práticas recomendadas, ajudando você a usar os fluxos de trabalho bem projetados, Já foram testados e sua eficiência é comprovada. Sua organização pode criar uma biblioteca de fluxos de trabalho reutilizáveis que pode ser mantida centralmente.
O diagrama abaixo mostra três trabalhos de criação à esquerda do diagrama. Depois que cada um desses trabalhos é concluído com sucesso, executa-se uma tarefa dependente denominada "Implantação". Esse trabalho chama um fluxo de trabalho reutilizável que contém três trabalhos: "Treinamento", "Revisão" e "Produção". A tarefa de implantação "Produção" só é executada após a tarefa de "Treinamento" ter sido concluída com sucesso. O uso um fluxo de trabalho reutilizável para executar trabalhos de implantação permite que você execute esses trabalhos para cada compilação sem duplicar o código nos fluxos de trabalho.
![Diagrama de um fluxo de trabalho reutilizável para implantação](/assets/images/help/images/reusable-workflows-ci-cd.png)
Um fluxo de trabalho que usa outro fluxo de trabalho é referido como um fluxo de trabalho "de chamada". O fluxo de trabalho reutilizável é um fluxo de trabalho "chamado". Um fluxo de trabalho de chamada pode usar vários fluxos de trabalho chamados. Cada fluxo de trabalho chamado é referenciado em uma única linha. O resultado é que o arquivo de fluxo de trabalho de chamadas pode conter apenas algumas linhas de YAML mas pode executar um grande número de tarefas quando for executado. Quando um fluxo de trabalho é reutilizado, todo o fluxo de trabalho chamado é usado, como se fosse parte do fluxo de trabalho de chamada.
Se você reutilizar um fluxo de trabalho de um repositório diferente, todas as ações no fluxo de trabalho chamado são como se fizessem parte do fluxo de trabalho de chamada. Por exemplo, se o fluxo de trabalho chamado usar `ações/checkout`, a ação verifica o conteúdo do repositório que hospeda o fluxo de trabalho de chamada, não o fluxo de trabalho chamado.
Quando um fluxo de trabalho reutilizável é acionado por um fluxo de trabalho de chamadas, o contexto `github` está sempre associado ao fluxo de trabalho de chamada. O fluxo de trabalho chamado tem acesso automaticamente a `github.token` e `secrets.GITHUB_TOKEN`. Para obter mais informações sobre o contexto do github ``, consulte "[Contexto e sintaxe de expressão para o GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)".
### Fluxos de trabalho e fluxo de trabalho inicial reutilizáveis
O fluxo de trabalho inicial permite que todos na sua organização que têm permissão criem fluxos de trabalho para fazê-lo de forma mais rápida e fácil. Quando as pessoas criam um novo fluxo de trabalho, eles podem escolher um fluxo de trabalho inicial e uma parte ou todo o trabalho de escrita do fluxo de trabalho será feito para essas pessoas. Dentro do fluxo de trabalho inicial, você também pode fazer referência a fluxos de trabalho reutilizáveis para facilitar o benefício das pessoas de reutilizar o código do fluxo de trabalho gerenciado centralmente. Se você usar uma tag ou nome de branch ao fazer referência ao fluxo de trabalho reutilizável, você poderá garantir que todos que reutilizarem esse fluxo de trabalho sempre usarão o mesmo código YAML. No entanto, se você fizer referência a um fluxo de trabalho reutilizável por uma tag ou branch, certifique-se de que você poderá confiar nessa versão do fluxo de trabalho. Para obter mais informações, consulte "[Fortalecimento da segurança para {% data variables.product.prodname_actions %}](/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows)".
Para obter mais informações, consulte "[Criando fluxos de trabalho iniciais para a sua organização](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)".
## Acesso a fluxos de trabalho reutilizáveis
Um fluxo de trabalho reutilizável pode ser usado por outro fluxo de trabalho se {% ifversion ghes or ghec or ghae %}qualquer{% else %}ou{% endif %} dos pontos a seguir for verdadeiro:
* Ambos os fluxos de trabalho estão no mesmo repositório.
* O fluxo de trabalho chamado é armazenado em um repositório público.{% ifversion ghes or ghec or ghae %}
* O fluxo de trabalho chamado é armazenado em um repositório interno e as configurações para esse repositório permitem que ele seja acessado. Para obter mais informações, consulte "[Gerenciar configurações de {% data variables.product.prodname_actions %} para um repositório](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository)".{% endif %}
## Usando executores
{% ifversion fpt or ghes or ghec %}
### Usar executores hospedados no GitHub
A atribuição de executores hospedados em {% data variables.product.prodname_dotcom %} é sempre avaliada usando apenas o contexto do chamador. A cobrança para executores hospedados em {% data variables.product.prodname_dotcom %} está sempre associada ao chamador. O fluxo de trabalho de chamadas não pode usar executores hospedados em {% data variables.product.prodname_dotcom %} a partir do repositório chamado. Para obter mais informações, consulte "[Sobre executores hospedados em {% data variables.product.prodname_dotcom %}](/actions/using-github-hosted-runners/about-github-hosted-runners)".
### Usando executores auto-hospedados
{% endif %}
Os fluxos de trabalho chamados podem acessar executores auto-hospedados no contexto do chamador. Isso significa que um fluxo de trabalho chamado pode acessar executores auto-hospedados que estão:
* No repositório de chamada
* Na organização{% ifversion ghes or ghec or ghae %} ou empresa {% endif %}do repositório de chamadas, desde que o executor tenha sido disponibilizado para o repositório de chamada
## Limitações
* Os fluxos de trabalho reutilizáveis não podem chamar outros fluxos de trabalho reutilizáveis.
* Os fluxos de trabalho armazenados dentro de um repositório privado só podem ser usados por fluxos de trabalho dentro do mesmo repositório.
* Qualquer variável de ambiente definida em um contexto `env` definido no nível do fluxo de trabalho no fluxo de trabalho da chamada não é propagada para o fluxo de trabalho chamado. Para obter mais informações sobre o contexto `env`, consulte "[Contexto e sintaxe de expressão para o GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#env-context)".
* A propriedade `estratégia` não é compatível com nenhum trabalho que chame um fluxo de trabalho reutilizável.
## Criar um fluxo de trabalho reutilizável
Os fluxos de trabalho reutilizáveis são arquivos formatados com YAML, muito semelhantes a qualquer outro arquivo de fluxo de trabalho. Como em outros arquivos de fluxo de trabalho, você localiza os fluxos de trabalho reutilizáveis no diretório `.github/workflows` de um repositório. Os subdiretórios do diretóriio `fluxos de trabalho` não são compatíveis.
Para que um fluxo de trabalho seja reutilizável, os valores de `on` devem incluir `workflow_call`:
```yaml
on:
workflow_call:
```
### Usando entradas e segredos em um fluxo de trabalho reutilizável
Você pode definir entradas e segredos, que podem ser passados do fluxo de trabalho de de chamada e, em seguida, usados no fluxo de trabalho chamado. Há três etapas para usar uma entrada ou um segredo em um fluxo de trabalho reutilizável.
1. No fluxo de trabalho reutilizável, use as palavras-chave `entradas` e `segredos` para definir entradas ou segredos que serão passados de um fluxo de trabalho chamado.
{% raw %}
```yaml
on:
workflow_call:
inputs:
username:
required: true
type: string
secrets:
envPAT:
required: true
```
{% endraw %}
Para obter detalhes da sintaxe para definir as entradas e segredos, consulte [`on.workflow_call.inputs`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callinputs) e [`on.workflow_call.secrets`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callsecrets).
1. Faça referência à entrada ou segredo no fluxo de trabalho reutilizável.
{% raw %}
```yaml
jobs:
reusable_workflow_job:
runs-on: ubuntu-latest
environment: production
steps:
- uses: ./.github/actions/my-action@v1
with:
username: ${{ inputs.username }}
token: ${{ secrets.envPAT }}
```
{% endraw %}
No exemplo acima, `envPAT` é um segredo de ambiente que foi adicionado ao ambiente de `produção`. Por conseguinte, este ambiente é mencionado no trabalho.
{% note %}
**Observação**: Os segredos do ambiente são strings criptografadas armazenadas em um ambiente que você definiu para um repositório. Os segredos de ambiente só estão disponíveis para trabalhos de fluxo de trabalho que fazem referência ao ambiente apropriado. Para obter mais informações, consulte "[Usando ambientes para implantação](/actions/deployment/targeting-different-environments/using-environments-for-deployment#environment-secrets)".
{% endnote %}
1. Passe a entrada ou o segredo do fluxo de trabalho da chamada.
{% indented_data_reference reusables.actions.pass-inputs-to-reusable-workflows spaces=3 %}
### Exemplo de fluxo de trabalho reutilizável
Este arquivo de workflow reutilizável chamado `workflow-B.yml` (faremos referência a ele mais adiante no [exemplo do fluxo de trabalho de chamada](#example-caller-workflow)) tem uma entrada e um segredo do fluxo de trabalho de chamadas e os usa em uma ação.
{% raw %}
```yaml{:copy}
name: Reusable workflow example
on:
workflow_call:
inputs:
username:
required: true
type: string
secrets:
token:
required: true
jobs:
example_job:
name: Pass input and secrets to my-action
runs-on: ubuntu-latest
steps:
- uses: ./.github/actions/my-action@v1
with:
username: ${{ inputs.username }}
token: ${{ secrets.token }}
```
{% endraw %}
## Chamando um fluxo de trabalho reutilizável
Você chama um fluxo de trabalho reutilizável usando a chave `usa`. Ao contrário de quando você usa ações em um fluxo de trabalho, você chama os fluxos de trabalho reutilizáveis diretamente em um trabalho, e não de dentro de etapas de trabalho.
[`jobs.<job_id>.uses`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_iduses)
Você faz referência a arquivos reutilizáveis do fluxo de trabalho usando a sintaxe:
`{owner}/{repo}/{path}/{filename}@{ref}`
Você pode chamar vários fluxos de trabalho, fazendo referência a cada um em um trabalho separado.
{% data reusables.actions.uses-keyword-example %}
### Passando entradas e segredos para um fluxo de trabalho reutilizável
{% data reusables.actions.pass-inputs-to-reusable-workflows%}
### Palavras-chave compatíveis com trabalhos que chamam um fluxo de trabalho reutilizável
Ao chamar um fluxo de trabalho reutilizável, você só poderá usar as palavras-chave a seguir no trabalho que contém a chamada:
* [`jobs.<job_id>.name`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idname)
* [`jobs.<job_id>.uses`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_iduses)
* [`jobs.<job_id>.with`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idwith)
* [`jobs.<job_id>.with.<input_id>`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idwithinput_id)
* [`jobs.<job_id>.secrets`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsecrets)
* [`jobs.<job_id>.secrets.<secret_id>`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsecretssecret_id)
* [`jobs.<job_id>.needs`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)
* [`jobs.<job_id>.if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif)
* [`jobs.<job_id>.permissions`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idpermissions)
{% note %}
**Observação:**
* Se `jobs.<job_id>.permissions` não for especificado no trabalho de chamadas, o fluxo de trabalho chamado terá as permissões padrão para o `GITHUB_TOKEN`. Para obter mais informações, consulte "[Autenticação em um fluxo de trabalho](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)".
* As permissões de `GITHUB_TOKEN` passadas do fluxo de trabalho de de cahamada só podem ser rebaixadas (não elevadas) pelo fluxo de trabalho chamado.
{% endnote %}
### Exemplo de fluxo de trabalho de chamada
Este arquivo de fluxo de trabalho chama dois arquivos de fluxo de trabalho. O segundo destes, `workflow-B.yml` (mostrado no exemplo [exemplo do fluxo de trabalho reutilizável](#example-reusable-workflow)), fica depois de uma entrada (`nome de usuário`) e um segredo (`token`).
{% raw %}
```yaml{:copy}
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:
uses: octo-org/example-repo/.github/workflows/workflow-B.yml@main
with:
username: mona
secrets:
token: ${{ secrets.TOKEN }}
```
{% endraw %}
## Usando saídas de um fluxo de trabalho reutilizável
Um fluxo de trabalho reutilizável pode gerar dados que você deseja usar no fluxo de trabalho da chamada. Para usar essas saídas, você deve especificá-las como saídas do fluxo de trabalho reutilizável.
O seguinte fluxo de trabalho reutilizável tem um único trabalho que contém duas etapas. Em cada uma dessas etapas, definimos uma única palavra como a saída: "olá" e "mundo". Na seção `saídas` do trabalho, nós mapeamos esses saídas de etapa para o trabalho chamada: `ouput1` e `ouput2`. Em seguida, na seção `on.workflow_call.outputs`, definimos duas saídas para o próprio fluxo de trabalho, uma chamada `firstword` que mapeamos com `output1`, e uma chamada `secondword` que mapeamos com `output2`.
{% raw %}
```yaml{:copy}
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 "::set-output name=firstword::hello"
- id: step2
run: echo "::set-output name=secondword::world"
```
{% endraw %}
Agora podemos usar as saídas no fluxo de trabalho da chamada, da mesma forma que você usaria as saídas de um trabalho dentro do mesmo fluxo de trabalho. Fazemos referência às saídas usando os nomes definidos no nível do fluxo de trabalho no fluxo de trabalho reutilizável: `firstword` e `secondword`. Neste fluxo de trabalho, `job1` chama o fluxo de trabalho reutilizável e `job2` imprime as saídas do fluxo de trabalho reutilizável ("hello world") para a saída padrão no registro do fluxo de trabalho.
{% raw %}
```yaml{:copy}
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 }}
```
{% endraw %}
Para obter mais informações sobre o uso de saídas de trabalho, consulte "[Sintaxe do Fluxo de trabalho para {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idoutputs)".
## Monitorando quais fluxos de trabalho estão sendo utilizados
Você pode usar a API REST de {% data variables.product.prodname_dotcom %} para monitorar como os fluxos de trabalho reutilizáveis são usados. A ação do log de auditoria `prepared_workflow_job` é acionada quando um trabalho de fluxo de trabalho é iniciado. Incluído nos dados registrados:
* `repo` - a organização/repositório onde o trabalho do fluxo de trabalho está localizado. Para um trabalho que chama outro fluxo de trabalho, este é a organização/repositório do fluxo de trabalho chamador.
* `@timestamp` - a data e a hora em que o trabalho foi iniciado, no formato epoch do Unix.
* `job_name` - o nome do trabalho executado.
* `job_workflow_ref` - o arquivo de fluxo de trabalho usado, no formato `{owner}/{repo}/{path}/{filename}@{ref}`. Para um trabalho que chama outro fluxo de trabalho, isso identifica o fluxo de trabalho chamado.
Para obter informações sobre o uso da API REST para consultar o log de auditoria para uma organização, consulte "[Organizações](/rest/reference/orgs#get-the-audit-log-for-an-organization)".
{% note %}
**Observação**: Os dados de auditoria para `prepared_workflow_job` só podem ser vistos usando a API REST. Eles não são visíveis na interface web de {% data variables.product.prodname_dotcom %} ou incluídos nos dados de auditoria exportados pelo JSON/CSV.
{% endnote %}
## Próximas etapas
Para continuar aprendendo sobre {% data variables.product.prodname_actions %}, consulte "[Eventos que desencadeiam fluxos de trabalho](/actions/learn-github-actions/events-that-trigger-workflows)".

54
translations/pt-BR/content/actions/learn-github-actions/sharing-workflows-secrets-and-runners-with-your-organization.md
View File

@@ -1,54 +0,0 @@
---
title: 'Compartilhando fluxos de trabalho, segredos e executores com a sua organização'
shortTitle: Compartilhar fluxos de trabalho com a sua organização
intro: 'Aprenda como usar recursos da organização para colaborar com a sua equipe, compartilhando fluxos de trabalho iniciantes, segredos e executores auto-hospedados.'
redirect_from:
- /actions/learn-github-actions/sharing-workflows-with-your-organization
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: how_to
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Visão Geral
Se você precisar compartilhar fluxos de trabalho e outros recursos de {% data variables.product.prodname_actions %} com a sua equipe, considere colaborar dentro de uma organização de {% data variables.product.prodname_dotcom %}. Uma organização permite que você armazene e gerencie, centralizadamente, segredos, artefatos e executores auto-hospedados. Você também pode criar um fluxo de trabalho inicial no repositório `.github` e compartilhá-lo com outros usuários na sua organização.
## Usando fluxos de trabalho iniciais
{% data reusables.actions.workflow-organization-templates %} Para obter mais informações, consulte "[Criando fluxos de trabalho iniciais para a sua organização](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)".
{% data reusables.actions.reusable-workflows %}
## Compartilhar segredos dentro de uma organização
Você pode gerenciar seus segredos centralmente dentro de uma organização e, em seguida, disponibilizá-los para repositórios selecionados. Isso também significa que você pode atualizar um segredo em um único local e fazer com que a alteração seja aplicada em todos os fluxos de trabalho do repositório que usam o segredo.
Ao criar um segredo em uma organização, você pode usar uma política para limitar quais repositórios podem acessar esse segredo. Por exemplo, você pode conceder acesso a todos os repositórios ou limitar o acesso a apenas repositórios privados ou a uma lista específica de repositórios.
{% data reusables.github-actions.permissions-statement-secrets-organization %}
{% data reusables.organizations.navigate-to-org %}
{% data reusables.organizations.org_settings %}
{% data reusables.github-actions.sidebar-secret %}
1. Clique em **Novo segredo**.
1. Digite um nome para o seu segredo na caixa de entrada **Nome**.
1. Insira o **Valor** para o seu segredo.
1. Na lista suspensa **Acesso do repositório**, escolha uma política de acesso.
1. Clique em **Add secret** (Adicionar segredo).
## Compartilhe executores auto-hospedados dentro de uma organização
Os administradores da organização podem adicionar seus executores auto-hospedados para grupos e, em seguida, criar políticas que controlam quais repositórios podem acessar o grupo.
Para obter mais informações, consulte "[Gerenciando acesso a runners auto-hospedados usando grupos](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups)".
## Próximas etapas
Para continuar aprendendo sobre {% data variables.product.prodname_actions %}, consulte "[Criando fluxos de trabalho iniciais para a sua organização](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)".

54
translations/pt-BR/content/actions/learn-github-actions/using-starter-workflows.md
View File

@@ -1,54 +0,0 @@
---
title: Usando fluxos de trabalho iniciais
intro: '{% data variables.product.product_name %} fornece fluxos de trabalho iniciais para uma série de linguagens e ferramentas.'
redirect_from:
- /articles/setting-up-continuous-integration-using-github-actions
- /github/automating-your-workflow-with-github-actions/setting-up-continuous-integration-using-github-actions
- /actions/automating-your-workflow-with-github-actions/setting-up-continuous-integration-using-github-actions
- /actions/building-and-testing-code-with-continuous-integration/setting-up-continuous-integration-using-github-actions
- /actions/guides/setting-up-continuous-integration-using-workflow-templates
- /actions/learn-github-actions/using-workflow-templates
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- Workflows
- CI
- CD
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Sobre fluxos de trabalho iniciais
{% data variables.product.product_name %} oferece fluxos de trabalho iniciantes para uma série de linguagens e ferramentas. Ao configurar os fluxos de trabalho no repositório, {% data variables.product.product_name %} analisa o código no seu repositório e recomenda fluxos de trabalho baseados na linguagem e na estrutura do seu repositório. Por exemplo, se você usar [Node.js](https://nodejs.org/en/), {% data variables.product.product_name %} irá sugerir um arquivo de fluxo de trabalho inicial que instala pacotes do seu Node.js e executa os seus testes.{% if actions-starter-template-ui %} Você pode pesquisar e filtrar para encontrar fluxos de trabalho iniciantes relevantes.{% endif %}
Você também pode criar seu próprio fluxo de trabalho inicial para compartilhar com sua organização. Estes fluxos de trabalho iniciais aparecerão junto com os fluxos de trabalho iniciais fornecidos por {% data variables.product.product_name %}. Para obter mais informações, consulte "[Criando fluxos de trabalho iniciais para a sua organização](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)".
## Usando fluxos de trabalho iniciais
Qualquer pessoa com a permissão de gravação em um repositório pode configurar fluxos de trabalho iniciais de {% data variables.product.prodname_actions %} para CI/CD ou outra automatização.
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.actions-tab %}
1. Se você já tem um fluxo de trabalho no seu repositório, clique em **Novo fluxo de trabalho**.
1. Localize o fluxo de trabalho inicial que deseja usar e, em seguida, clique em **Configurar este fluxo de trabalho**.{% if actions-starter-template-ui %} Para ajudá-lo a encontrar o fluxo de trabalho inicial que você quer, você pode procurar por palavras-chave ou filtrar por categoria.{% endif %}
1. Se o fluxo de trabalho inicial contiver comentários que detalham as etapas de instalação adicionais, siga estas etapas. Muitos dos fluxos de trabalho iniciais têm guias correspondentes. Para obter mais informações, consulte [os guias de {% data variables.product.prodname_actions %}](/actions/guides).
1. Alguns fluxos de trabalho iniciais usam segredos. Por exemplo, {% raw %}`${{ secrets.npm_token }}`{% endraw %}. Se o fluxo de trabalho inicial usar um segredo, armazene o valor descrito no nome do segredo como um segredo no repositório. Para obter mais informações, consulte "[Segredos criptografados](/actions/reference/encrypted-secrets)".
1. Opcionalmente, faça as alterações adicionais. Por exemplo, talvez você queira alterar o valor de `on` para mudar quando o fluxo de trabalho é executado.
1. Clique em **Start commit** (Iniciar commit).
1. Escreva uma mensagem de commit e decida se você deseja de fazer o commit diretamente para o branch padrão ou abrir um pull request.
## Leia mais
- [Sobre integração contínua](/articles/about-continuous-integration)
- "[Gerenciando execuções de fluxo de trabalho](/actions/managing-workflow-runs)"
- "[Sobre o monitoramento e solução de problemas](/actions/monitoring-and-troubleshooting-workflows/about-monitoring-and-troubleshooting)"
- "[Aprenda {% data variables.product.prodname_actions %}](/actions/learn-github-actions)"
{% ifversion fpt or ghec %}
- "[Gerenciando cobrança para {% data variables.product.prodname_actions %}](/billing/managing-billing-for-github-actions)"
{% endif %}

413
translations/pt-BR/content/actions/learn-github-actions/workflow-commands-for-github-actions.md
View File

@@ -1,413 +0,0 @@
---
title: Comandos do fluxo de trabalho para o GitHub Actions
shortTitle: Comandos do fluxo de trabalho
intro: Você pode usar comandos do fluxo de trabalho ao executar comandos do shell em um fluxo de trabalho ou no código de uma ação.
redirect_from:
- /articles/development-tools-for-github-actions
- /github/automating-your-workflow-with-github-actions/development-tools-for-github-actions
- /actions/automating-your-workflow-with-github-actions/development-tools-for-github-actions
- /actions/reference/development-tools-for-github-actions
- /actions/reference/logging-commands-for-github-actions
- /actions/reference/workflow-commands-for-github-actions
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Sobre os comandos do fluxo de trabalho
As ações podem comunicar-se com a máquina do executor para definir as variáveis de ambiente, valores de saída usados por outras ações, adicionar mensagens de depuração aos registros de saída e outras tarefas.
A maioria dos comandos de fluxo de trabalho usa o comando `echo` em um formato específico, enquanto outros são chamados escrevendo um arquivo. Para obter mais informações, consulte ["Arquivos de ambiente".](#environment-files)
``` bash
echo "::workflow-command parameter1={data},parameter2={data}::{command value}"
```
{% note %}
**Observação:** Os nomes do comando do fluxo de trabalho e do parâmetro não diferenciam maiúsculas e minúsculas.
{% endnote %}
{% warning %}
**Aviso:** se você estiver usando um prompt do comando, omita as aspas duplas (`"`) ao usar comandos do fluxo de trabalho.
{% endwarning %}
## Usar comandos do fluxo de trabalho para acessar funções do kit de de ferramentas
O [actions/toolkit](https://github.com/actions/toolkit) inclui uma quantidade de funções que podem ser executadas como comandos do fluxo de trabalho. Use a sintaxe `::` para executar os comandos do fluxo de trabalho no arquivo YAML. Em seguida, esses comandos serão enviados para a o executor por meio do `stdout`. Por exemplo, em vez de usar o código para definir uma saída, como abaixo:
```javascript
core.setOutput('SELECTED_COLOR', 'green');
```
Você pode usar o comando `set-output` no seu fluxo de trabalho para definir o mesmo valor:
{% raw %}
``` yaml
- name: Set selected color
run: echo '::set-output name=SELECTED_COLOR::green'
id: random-color-generator
- name: Get color
run: echo "The selected color is ${{ steps.random-color-generator.outputs.SELECTED_COLOR }}"
```
{% endraw %}
A tabela a seguir mostra quais funções do conjunto de ferramentas estão disponíveis dentro de um fluxo de trabalho:
| Função do kit de ferramentas | Comando equivalente do fluxo de trabalho |
| ---------------------------- | --------------------------------------------------------------------- |
| `core.addPath` | Acessível usando o arquivo de ambiente `GITHUB_PATH` |
| `core.debug` | `debug` |{% ifversion fpt or ghes > 3.2 or ghae-issue-4929 or ghec %}
| `core.notice` | `notice`
{% endif %}
| `core.error` | `erro` |
| `core.endGroup` | `endgroup` |
| `core.exportVariable` | Acessível usando o arquivo de ambiente `GITHUB_ENV` |
| `core.getInput` | Acessível por meio do uso da variável de ambiente `INPUT_{NAME}` |
| `core.getState` | Acessível por meio do uso da variável de ambiente `STATE_{NAME}` |
| `core.isDebug` | Acessível por meio do uso da variável de ambiente `RUNNER_DEBUG` |
| `core.saveState` | `save-state` |
| `core.setCommandEcho` | `echo` |
| `core.setFailed` | Usado como um atalho para `::error` e `exit 1` |
| `core.setOutput` | `set-output` |
| `core.setSecret` | `add-mask` |
| `core.startGroup` | `grupo` |
| `core.warning` | `aviso` |
## Definir um parâmetro de saída
```
::set-output name={name}::{value}
```
Configura um parâmetro de saída da ação.
Opcionalmente, você também pode declarar os parâmetros de saída no arquivo de metadados de uma ação. Para obter mais informações, consulte "[Sintaxe de metadados para o {% data variables.product.prodname_actions %}](/articles/metadata-syntax-for-github-actions#outputs)".
### Exemplo
``` bash
echo "::set-output name=action_fruit::strawberry"
```
## Configurar uma mensagem de depuração
```
::debug::{message}
```
Imprime uma mensagem de erro no log. Você deve criar um segredo nomeado `ACTIONS_STEP_DEBUG` com o valor `true` para ver as mensagens de erro configuradas por esse comando no log. Para obter mais informações, consulte "[Habilitar o registro de depuração](/actions/managing-workflow-runs/enabling-debug-logging)".
### Exemplo
``` bash
echo "::debug::Set the Octocat variable"
```
{% ifversion fpt or ghes > 3.2 or ghae-issue-4929 or ghec %}
## Configurando uma mensagem de aviso
```
::notice file={name},line={line},endLine={endLine},title={title}::{message}
```
Cria uma mensagem de aviso e a imprime no registro. {% data reusables.actions.message-annotation-explanation %}
{% data reusables.actions.message-parameters %}
### Exemplo
``` bash
echo "::notice file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
```
{% endif %}
## Configurar uma mensagem de aviso
```
::warning file={name},line={line},endLine={endLine},title={title}::{message}
```
Cria uma mensagem de aviso e a imprime no log. {% data reusables.actions.message-annotation-explanation %}
{% data reusables.actions.message-parameters %}
### Exemplo
``` bash
echo "::warning file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
```
## Configurar uma mensagem de erro
```
::error file={name},line={line},endLine={endLine},title={title}::{message}
```
Cria uma mensagem de erro e a imprime no log. {% data reusables.actions.message-annotation-explanation %}
{% data reusables.actions.message-parameters %}
### Exemplo
``` bash
echo "::error file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
```
## Agrupar linhas dos registros
```
::group::{title}
::endgroup::
```
Cria um grupo expansível no registro. Para criar um grupo, use o comando `grupo` e especifique um `título`. Qualquer coisa que você imprimir no registro entre os comandos `grupo` e `endgroup` estará aninhada dentro de uma entrada expansível no registro.
### Exemplo
```bash
echo "::group::My title"
echo "Inside group"
echo "::endgroup::"
```
![Grupo dobrável no registro da execução do fluxo de trabalho](/assets/images/actions-log-group.png)
## Mascarar um valor no registro
```
::add-mask::{value}
```
Mascarar um valor evita que uma string ou variável seja impressa no log. Cada palavra mascarada separada por espaço em branco é substituída pelo caractere `*`. Você pode usar uma variável de ambiente ou string para o `value` da máscara.
### Exemplo de máscara de string
Quando você imprime `"Mona The Octocat"` no log, você verá `"***"`.
```bash
echo "::add-mask::Mona The Octocat"
```
### Exemplo de máscara de uma variável de ambiente
Ao imprimir a variável `MY_NAME` ou o valor `"Mona The Octocat"` no log, você verá `"***"` em vez de `"Mona The Octocat"`.
```bash
MY_NAME="Mona The Octocat"
echo "::add-mask::$MY_NAME"
```
## Parar e iniciar os comandos no fluxo de trabalho
`::stop-commands::{endtoken}`
Para de processar quaisquer comandos de fluxo de trabalho. Esse comando especial permite fazer o registro do que você desejar sem executar um comando do fluxo de trabalho acidentalmente. Por exemplo, é possível parar o log para gerar um script inteiro que tenha comentários.
Para parar o processamento de comandos de fluxo de trabalho, passe um token único para `stop-commands`. Para retomar os comandos do fluxo de trabalho, passe o mesmo token que você usou para parar os comandos do fluxo de trabalho.
{% warning %}
**Aviso:** Certifique-se de que o token que você está usando é gerado aleatoriamente e exclusivo para cada execução. Como demonstrado no exemplo abaixo, você pode gerar um hash exclusivo do seu `github.token` para cada execução.
{% endwarning %}
```
::{endtoken}::
```
### Exemplo de parar e iniciar comandos de workflow
{% raw %}
```yaml
jobs:
workflow-command-job:
runs-on: ubuntu-latest
steps:
- name: disable workflow commands
run: |
echo '::warning:: this is a warning'
echo "::stop-commands::`echo -n ${{ github.token }} | sha256sum | head -c 64`"
echo '::warning:: this will NOT be a warning'
echo "::`echo -n ${{ github.token }} | sha256sum | head -c 64`::"
echo '::warning:: this is a warning again'
```
{% endraw %}
## Eco de saídas de comando
```
::echo::on
::echo::off
```
Habilita ou desabilita o eco de comandos de fluxo de trabalho. Por exemplo, se você usar o comando `set-output` em um fluxo de trabalho, ele definirá um parâmetro de saída, mas o registro da execução do fluxo de trabalho não irá mostrar o comando em si. Se você habilitar o comando de eco, o registro mostrará o comando, como `::set-output name={name}::{value}`.
O eco de comandos encontra-se desabilitado por padrão. No entanto, um comando de fluxo de trabalho será refletido se houver algum erro que processa o comando.
Os comandos `add-mask`, `depurar`, `aviso` e `erro` não são compatíveis com o eco, porque suas saídas já estão ecoadas no registros.
Você também pode habilitar o comando de eco globalmente ativando o registrode depuração da etapa usando o segredo `ACTIONS_STEP_DEBUG`. Para obter mais informações, consulte[Habilitando o log de depuração](/actions/managing-workflow-runs/enabling-debug-logging)". Em contraste, o comando do fluxo de trabalho `echo` permite que você habilite o comando de eco em um nível mais granular em vez de habilitá-lo para cada fluxo de trabalho em um repositório.
### Exemplo de alternar o comando do eco
```yaml
jobs:
workflow-command-job:
runs-on: ubuntu-latest
steps:
- name: toggle workflow command echoing
run: |
echo '::set-output name=action_echo::disabled'
echo '::echo::on'
echo '::set-output name=action_echo::enabled'
echo '::echo::off'
echo '::set-output name=action_echo::disabled'
```
A etapa acima imprime as seguintes linhas no registro:
```
::set-output name=action_echo::enabled
::echo::off
```
Apenas os comandos do fluxo de trabalho `set-output` e `echo` estão incluídos no registro, porque o recurso de comandos só estava habilitado quando eles foram executados. Mesmo que nem sempre ele esteja ecoado, o parâmetro de saída é definido em todos os casos.
## Enviar valores para as ações anterior e posterior
Você pode usar o comando `save-state` para criar variáveis de ambiente para compartilhar com as ações `pre:` ou `post:`. Por exemplo, você pode criar um arquivo com a ação `pre:`, passar o local do arquivo para a ação `main:` e, em seguida, usar a ação `post:` para excluir o arquivo. Como alternativa, você pode criar um arquivo com a ação `main:` ação, passar o local do arquivo para a ação `post:`, além de usar a ação `post:` para excluir o arquivo.
Se você tiver múltiplas ações `pre:` ou `post:` ações, você poderá apenas acessar o valor salvo na ação em que `save-state` foi usado. Para obter mais informações sobre a ação `post:`, consulte "[Sintaxe de metadados para {% data variables.product.prodname_actions %}](/actions/creating-actions/metadata-syntax-for-github-actions#post)".
O comando `save-state` pode ser executado apenas em uma ação e não está disponível para arquivos YAML. O valor salvo é armazenado como um valor de ambiente com o prefixo `STATE_`.
Este exemplo usa o JavaScript para executar o comando `save-state`. A variável de ambiente resultante é denominada `STATE_processID` com o valor de `12345`:
``` javascript
console.log('::save-state name=processID::12345')
```
A variável `STATE_processID` está exclusivamente disponível para o script de limpeza executado na ação `principal`. Este exemplo é executado em `principal` e usa o JavaScript para exibir o valor atribuído à variável de ambiente `STATE_processID`:
``` javascript
console.log("O PID em execução a partir da ação principal é: " + process.env.STATE_processID);
```
## Arquivos de Ambiente
Durante a execução de um fluxo de trabalho, o executor gera arquivos temporários que podem ser usados para executar certas ações. O caminho para esses arquivos são expostos através de variáveis de ambiente. Você precisará usar a codificação UTF-8 ao escrever para esses arquivos para garantir o processamento adequado dos comandos. Vários comandos podem ser escritos no mesmo arquivo, separados por novas linhas.
{% warning %}
**Aviso:** no Windows, o PowerShell de legado (`shell: powershell`) não usa UTF-8 por padrão. Certifique-se de escrever os arquivos usando a codificação correta. Por exemplo, você deve definir a codificação UTF-8 ao definir o caminho:
```yaml
jobs:
legacy-powershell-example:
uses: windows-2019
steps:
- shell: powershell
run: echo "mypath" | Out-File -FilePath $env:GITHUB_PATH -Encoding utf8 -Append
```
Ou mude para PowerShell Core, cujo padrão é UTF-8:
```yaml
jobs:
modern-pwsh-example:
uses: windows-2019
steps:
- shell: pwsh
run: echo "mypath" | Out-File -FilePath $env:GITHUB_PATH -Append # no need for -Encoding utf8
```
Mais detalhes sobre UTF-8 e PowerShell Core encontrados nesta excelente [resposta do Stack Overflow](https://stackoverflow.com/a/40098904/162694):
> ### Leitura opcional: A perspectiva entre plataformas: PowerShell _Core_:
>
> [O PowerShell agora é multiplataforma](https://blogs.msdn.microsoft.com/powershell/2016/08/18/powershell-on-linux-and-open-source-2/), por meio da sua edição do **[PowerShell _Core_](https://github.com/PowerShell/PowerShell)**, cuja codificação - sensívelmente - *** é igual a ***BOM-less UTF-8******, em linha com plataformas do Unix.
{% endwarning %}
## Definir uma variável de ambiente
``` bash
echo "{name}={value}" >> $GITHUB_ENV
```
Cria ou atualiza uma variável de ambiente para quaisquer etapas a serem executadas em seguida no trabalho. A etapa que cria ou atualiza a variável de ambiente não tem acesso ao novo valor, mas todos os passos subsequentes em um trabalho terão acesso. As variáveis de ambiente diferenciam maiúsculas de minúsculas e podem ter pontuação.
{% note %}
**Observação:** As variáveis de ambiente devem ser referenciadas explicitamente usando o [`env` contexto](/actions/reference/context-and-expression-syntax-for-github-actions#env-context) na sintaxe de expressão ou por meio do uso do arquivo `$GITHUB_ENV` diretamente. As variáveisde ambiente não estão implicitamente disponíveis nos comandos do shell.
{% endnote %}
### Exemplo
{% raw %}
```
steps:
- name: Set the value
id: step_one
run: |
echo "action_state=yellow" >> $GITHUB_ENV
- name: Use the value
id: step_two
run: |
echo "${{ env.action_state }}" # This will output 'yellow'
```
{% endraw %}
### Strings de linha múltipla
Para strings linha múltipla, você pode usar um delimitador com a seguinte sintaxe.
```
{name}<<{delimiter}
{value}
{delimiter}
```
#### Exemplo
Neste exemplo, usamos `EOF` como um delimitador e definimos a variável de ambiente `JSON_RESPONSE` como o valor da resposta de curl.
```yaml
steps:
- name: Set the value
id: step_one
run: |
echo 'JSON_RESPONSE<<EOF' >> $GITHUB_ENV
curl https://httpbin.org/json >> $GITHUB_ENV
echo 'EOF' >> $GITHUB_ENV
```
## Adicionar um caminho do sistema
``` bash
echo "{path}" >> $GITHUB_PATH
```
Prepara um diretório para a variável `PATH` do sistema e disponibiliza automaticamente para todas as ações subsequentes no trabalho atual; a ação atualmente em execução não pode acessar a variável de caminho atualizada. Para ver os caminhos atualmente definidos para o seu trabalho, você pode usar o `echo "$PATH"` em uma etapa ou ação.
### Exemplo
Este exemplo demonstra como adicionar o diretório `$HOME/.local/bin` ao `PATH`:
``` bash
echo "$HOME/.local/bin" >> $GITHUB_PATH
```

1706
translations/pt-BR/content/actions/learn-github-actions/workflow-syntax-for-github-actions.md
View File

File diff suppressed because it is too large Load Diff

99
translations/zh-CN/content/actions/learn-github-actions/creating-starter-workflows-for-your-organization.md
View File

@@ -1,99 +0,0 @@
---
title: Creating starter workflows for your organization
shortTitle: Creating starter workflows
intro: Learn how you can create starter workflows to help people in your team add new workflows more easily.
redirect_from:
- /actions/configuring-and-managing-workflows/sharing-workflow-templates-within-your-organization
- /actions/learn-github-actions/creating-workflow-templates
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- Workflows
- CI
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## 概览
{% data reusables.actions.workflow-organization-templates %}
## Creating a starter workflow
Starter workflows can be created by users with write access to the organization's `.github` repository. These can then be used by organization members who have permission to create workflows.
{% ifversion fpt %}
Starter workflows created by users can only be used to create workflows in public repositories. Organizations using {% data variables.product.prodname_ghe_cloud %} can also use starter workflows to create workflows in private repositories. For more information, see the [{% data variables.product.prodname_ghe_cloud %} documentation](/enterprise-cloud@latest/actions/learn-github-actions/creating-starter-workflows-for-your-organization).
{% endif %}
{% ifversion fpt or ghes > 3.3 or ghae-issue-4757 or ghec %}
{% note %}
**Note:** To avoid duplication among starter workflows you can call reusable workflows from within a workflow. This can help make your workflows easier to maintain. For more information, see "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)."
{% endnote %}
{% endif %}
This procedure demonstrates how to create a starter workflow and metadata file. The metadata file describes how the starter workflows will be presented to users when they are creating a new workflow.
1. 如果组织中没有名为 `.github` 的公共仓库，请新建一个。
2. 创建一个名为 `workflow-templates` 的目录。
3. 在 `workflow-templates` 目录中创建新的工作流程文件。
如果需要引用仓库的默认分支，可以使用 `$default-branch` 占位符。 When a workflow is created the placeholder will be automatically replaced with the name of the repository's default branch.
例如，下面这个名为 `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@v2
- name: Run a one-line script
run: echo Hello from Octo Organization
```
4. 在 `workflow-templates` 目录中创建元数据文件。 元数据文件必须与工作流程文件同名，但扩展名不是 `.yml`，而必须附加 `.properties.json`。 例如，下面这个名为 `octo-organization-ci.properties.json` 的文件包含名为 `octo-organization-ci.yml` 的工作流程文件的元数据：
```yaml
{
"name": "Octo Organization Workflow",
"description": "Octo Organization CI starter workflow.",
"iconName": "example-icon",
"categories": [
"Go"
],
"filePatterns": [
"package.json$",
"^Dockerfile",
".*\\.md$"
]
}
```
* `name` - **Required.** The name of the workflow. This is displayed in the list of available workflows.
* `description` - **Required.** The description of the workflow. This is displayed in the list of available workflows.
* `iconName` - **Optional.** Specifies an icon for the workflow that's displayed in the list of workflows. The `iconName` must be the name of an SVG file, without the file name extension, stored in the `workflow-templates` directory. For example, an SVG file named `example-icon.svg` is referenced as `example-icon`.
* `categories` - **可选。**定义工作流程的语言类别。 When a user views the available starter workflows for a repository, the workflows that match the identified language for the project are featured more prominently. 有关可用语言类别的信息，请参阅https://github.com/github/linguist/blob/master/lib/linguist/languages.yml。
* `filePatterns` - **Optional.** Allows the workflow to be used if the user's repository has a file in its root directory that matches a defined regular expression.
To add another starter workflow, add your files to the same `workflow-templates` directory. 例如：
![Workflow files](/assets/images/help/images/workflow-template-files.png)
## 后续步骤
To continue learning about {% data variables.product.prodname_actions %}, see "[Using starter workflows](/actions/learn-github-actions/using-starter-workflows)."

865
translations/zh-CN/content/actions/learn-github-actions/events-that-trigger-workflows.md
View File

@@ -1,865 +0,0 @@
---
title: 触发工作流程的事件
intro: '您可以配置工作流程在 {% data variables.product.product_name %} 上发生特定活动时运行、在预定的时间运行，或者在 {% data variables.product.product_name %} 外部的事件发生时运行。'
miniTocMaxHeadingLevel: 3
redirect_from:
- /articles/events-that-trigger-workflows
- /github/automating-your-workflow-with-github-actions/events-that-trigger-workflows
- /actions/automating-your-workflow-with-github-actions/events-that-trigger-workflows
- /actions/reference/events-that-trigger-workflows
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
shortTitle: 触发工作流程的事件
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## 配置工作流程事件
您可以使用 `on` 工作流程语法配置工作流程为一个或多个事件运行。 更多信息请参阅“[{% data variables.product.prodname_actions %} 的工作流程语法](/articles/workflow-syntax-for-github-actions#on)”。
{% data reusables.github-actions.actions-on-examples %}
{% note %}
**注意：**无法使用 `GITHUB_TOKEN` 触发新的工作流程。 更多信息请参阅“[使用个人访问令牌触发新的工作流程](#triggering-new-workflows-using-a-personal-access-token)”。
{% endnote %}
以下步骤将触发工作流程运行：
1. 仓库中发生事件，生成的事件具有关联的提交 SHA 和 Git ref。
2. 在仓库的 `.github/workflow` 目录中关联的提交 SHA 或 Git ref 处搜索工作流程文件。 工作流程文件必须存在于该提交 SHA 或 Git ref 中才会被考虑。
例如，如果事件发生在特定仓库分支上，则工作流程文件必须存在于该分支的仓库中。
1. 检查该提交 SHA 和 Git ref 的工作流程文件， 并且对其 `on:` 值与触发事件匹配的任何工作流程触发新的工作流程。
工作流程在触发事件的相同提交 SHA 和 Git ref 上的仓库代码中运行。 当工作流程运行时，{% data variables.product.product_name %} 会在运行器环境中设置 `GITHUB_SHA`（提交 SHA）和 `GITHUB_REF`（Git 引用）环境变量。 更多信息请参阅“[使用环境变量](/actions/automating-your-workflow-with-github-actions/using-environment-variables)”。
## 安排的事件
`schedule` 事件允许您在计划的时间触发工作流程。
{% data reusables.actions.schedule-delay %}
### `计划`
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------ | ---- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| n/a | n/a | 默认分支上的最新提交 | 默认分支 | 安排的工作流程设置为运行。 预定的工作流程使用 [POSIX 计划任务语法](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07)。 更多信息请参阅“[通过事件触发工作流程](/articles/configuring-a-workflow/#triggering-a-workflow-with-events)”。 |
{% data reusables.repositories.actions-scheduled-workflow-example %}
计划任务语法有五个字段，中间用空格分隔，每个字段代表一个时间单位。
```
┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
* * * * *
```
您可在这五个字段中使用以下运算符：
| 运算符 | 描述 | 示例 |
| --- | ------ | ------------------------------------------------------------ |
| * | 任意值 | `* * * * *` 在每天的每分钟运行。 |
| , | 值列表分隔符 | `2,10 4,5 * * *` 在每天第 4 和第 5 小时的第 2 和第 10 分钟运行。 |
| - | 值的范围 | `0 4-6 * * *` 在第 4、5、6 小时的第 0 分钟运行。 |
| / | 步骤值 | `20/15 * * * *` 从第 20 分钟到第 59 分钟每隔 15 分钟运行（第 20、35 和 50 分钟）。 |
{% note %}
**注：** {% data variables.product.prodname_actions %} 不支持非标准语法 `@yearly`、`@monthly`、`@weekly`、`@daily`、`@hourly` 和 `@reboot`。
{% endnote %}
您可以使用 [crontab guru](https://crontab.guru/) 帮助生成计划任务语法并确认它在何时运行。 为帮助您开始，我们还提供了一系列 [crontab guru 示例](https://crontab.guru/examples.html)。
计划工作流程的通知将发送给最后修改工作流程文件中的 cron 语法的用户。 更多信息请参阅“[工作流程运行通知](/actions/guides/about-continuous-integration#notifications-for-workflow-runs)”。
## 手动事件
您可以手动触发工作流程运行。 要触发仓库中的特定工作流程，请使用 `workflow_dispatch` 事件。 要触发仓库中的多个工作流程并创建自定义事件和事件类型，请使用 `repository_dispatch` 事件。
### `workflow_dispatch`
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------- | ---- | --------------------- | ------------ |
| [workflow_dispatch](/webhooks/event-payloads/#workflow_dispatch) | n/a | `GITHUB_REF` 分支上的最新提交 | 收到了分发的分支 |
您可以直接在工作流程中配置事件的自定义输入属性、默认输入值和必要输入。 当工作流程运行时，您可以访问 `github.event.inputs` 上下文中的输入值。 更多信息请参阅“[上下文](/actions/learn-github-actions/contexts)”。
You can manually trigger a workflow run using the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API and from {% data variables.product.product_name %}. 更多信息请参阅“[手动配置工作流程](/actions/managing-workflow-runs/manually-running-a-workflow)。
当您在 {% data variables.product.prodname_dotcom %} 上触发事件时，可以在 {% data variables.product.prodname_dotcom %} 上直接提供 `ref` 和任何 `inputs`。 更多信息请参阅“[对操作使用输入和输出](/actions/learn-github-actions/finding-and-customizing-actions#using-inputs-and-outputs-with-an-action)”。
To trigger the custom `workflow_dispatch` webhook event using the REST API, you must send a `POST` request to a {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API endpoint and provide the `ref` and any required `inputs`. 更多信息请参阅“[创建工作流程调度事件](/rest/reference/actions/#create-a-workflow-dispatch-event)”REST API 端点。
#### 示例
要使用 `Workflow_paid` 事件，您需要将其作为触发器包含在您的 GitHub Actions 工作流程文件中。 下面的示例仅在手动触发时运行工作流程：
```yaml
on: workflow_dispatch
```
#### 示例工作流程配置
此示例定义了 `name` 和 `home` 输入，并使用 `github.event.inputs.name` 和 `github.event.inputs.home` 上下文打印。 如果未提供 `home` ，则打印默认值“The Octoverse”。
{% raw %}
```yaml
name: Manually triggered workflow
on:
workflow_dispatch:
inputs:
name:
description: 'Person to greet'
required: true
default: 'Mona the Octocat'
home:
description: 'location'
required: false
default: 'The Octoverse'
jobs:
say_hello:
runs-on: ubuntu-latest
steps:
- run: |
echo "Hello ${{ github.event.inputs.name }}!"
echo "- in ${{ github.event.inputs.home }}!"
```
{% endraw %}
### `repository_dispatch`
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------------------- | ---- | ------------ | ------------ |
| [repository_dispatch](/webhooks/event-payloads/#repository_dispatch) | n/a | 默认分支上的最新提交 | 默认分支 |
{% data reusables.github-actions.branch-requirement %}
You can use the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API to trigger a webhook event called [`repository_dispatch`](/webhooks/event-payloads/#repository_dispatch) when you want to trigger a workflow for activity that happens outside of {% data variables.product.prodname_dotcom %}. 更多信息请参阅“[创建仓库调度事件](/rest/reference/repos#create-a-repository-dispatch-event)”。
To trigger the custom `repository_dispatch` webhook event, you must send a `POST` request to a {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API endpoint and provide an `event_type` name to describe the activity type. 要触发工作流程运行，还必须配置工作流程使用 `repository_dispatch` 事件。
#### 示例
默认情况下，所有 `event_types` 都会触发工作流程运行。 您可以限制工作流程在 `repository_dispatch` web 挂钩有效负载中发送特定 `event_type` 值时运行。 创建仓库调度事件时定义在 `repository_dispatch` 有效负载中发送的事件类型。
```yaml
on:
repository_dispatch:
types: [opened, deleted]
```
{% ifversion fpt or ghes > 3.3 or ghae-issue-4757 or ghec %}
## Workflow reuse events
`workflow_call` is a keyword used as the value of `on` in a workflow, in the same way as an event. It indicates that a workflow can be called from another workflow. For more information see, "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)."
### `workflow_call`
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------- | ---- | --------------------------- | --------------------------- |
| Same as the caller workflow | n/a | Same as the caller workflow | Same as the caller workflow |
#### 示例
To make a workflow reusable it must include `workflow_call` as one of the values of `on`. The example below only runs the workflow when it's called from another workflow:
```yaml
on: workflow_call
```
{% endif %}
## Web 挂钩事件
您可以将工作流程配置为在 {% data variables.product.product_name %} 上生成 web 挂钩事件时运行。 某些事件有多种触发事件的活动类型。 如果有多种活动类型触发事件，则可以指定哪些活动类型将触发工作流程运行。 更多信息请参阅“[web 挂钩](/webhooks)”。
并非所有 web 挂钩事件都触发工作流程。 要了解可用 web 挂钩事件及其有效负载的完整列表，请参阅“[web 挂钩事件和有效负载](/developers/webhooks-and-events/webhook-events-and-payloads)”。
{% ifversion fpt or ghec or ghes > 3.3 or ghae-issue-4968 %}
### `branch_protection_rule`
Runs your workflow anytime the `branch_protection_rule` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the GraphQL API, see "[BranchProtectionRule]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql/reference/objects#branchprotectionrule)."
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------------- | ------------------------------------------------------ | ------------ | ------------ |
| [`branch_protection_rule`](/webhooks/event-payloads/#branch_protection_rule) | - `created`<br/>- `edited`<br/>- `deleted` | 默认分支上的最新提交 | 默认分支 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
For example, you can run a workflow when a branch protection rule has been `created` or `deleted`.
```yaml
on:
branch_protection_rule:
types: [created, deleted]
```
{% endif %}
### `check_run`
在发生 `check_run` 事件的任何时间运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %}有关 REST API 的信息，请参阅“[检查运行](/rest/reference/checks#runs)”。
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------- | ------------------------------------------------------------- | ------------ | ------------ |
| [`check_run`](/webhooks/event-payloads/#check_run) | - `created`<br/>- `rerequested`<br/>- `completed` | 默认分支上的最新提交 | 默认分支 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在检查运行为 `rerequested` 或 `completed` 时运行工作流程。
```yaml
on:
check_run:
types: [rerequested, completed]
```
### `check_suite`
在发生 `check_suite` 事件的任何时间运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %}有关 REST API 的信息，请参阅“[检查套件](/rest/reference/checks#suites)”。
{% data reusables.github-actions.branch-requirement %}
{% note %}
**注意：**为防止递归工作流程，如果检查套件是由 {% data variables.product.prodname_actions %} 创建的，则此事件不会触发工作流程。
{% endnote %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------ | -------------------------------------------------------------------------- | ------------ | ------------ |
| [`check_suite`](/webhooks/event-payloads/#check_suite) | - `completed`<br/>- `requested`<br/>- `rerequested`<br/> | 默认分支上的最新提交 | 默认分支 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在检查套件为 `rerequested` 或 `completed` 时运行工作流程。
```yaml
on:
check_suite:
types: [rerequested, completed]
```
### `create`
每当有人创建分支或标记（触发 `create` 事件）时运行您的工作流程。 有关 REST API 的信息，请参阅“[创建引用](/rest/reference/git#create-a-reference)”。
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------- | ---- | -------------- | ------------ |
| [`create`](/webhooks/event-payloads/#create) | n/a | 创建的分支或标记上的最新提交 | 创建的分支或标记 |
例如，您可以在发生 `create` 事件时运行工作流程。
```yaml
on:
create
```
### `delete`
每当有人删除分支或标记（触发 `delete` 事件）时运行您的工作流程。 有关 REST API 的信息，请参阅“[删除引用](/rest/reference/git#delete-a-reference)”。
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------- | ---- | ------------ | ------------ |
| [`delete`](/webhooks/event-payloads/#delete) | n/a | 默认分支上的最新提交 | 默认分支 |
例如，您可以在发生 `delete` 事件时运行工作流程。
```yaml
on:
delete
```
### `deployment`
每当有人创建部署（触发 `deployment` 事件）时运行您的工作流程。 使用提交 SHA 创建的部署可能没有 Git 引用。 有关 REST API 的信息，请参阅“[部署](/rest/reference/repos#deployments)”。
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------- | ---- | ------------ | ---------------- |
| [`deployment`](/webhooks/event-payloads/#deployment) | n/a | 要部署的提交 | 要部署的分支或标记（提交时为空） |
例如，您可以在发生 `deployment` 事件时运行工作流程。
```yaml
on:
deployment
```
### `deployment_status`
每当第三方提供部署状态（触发 `deployment_status` 事件）时运行您的工作流程。 使用提交 SHA 创建的部署可能没有 Git 引用。 有关 REST API 的信息，请参阅“[创建部署状态](/rest/reference/deployments#create-a-deployment-status)”。
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------ | ---- | ------------ | ---------------- |
| [`deployment_status`](/webhooks/event-payloads/#deployment_status) | n/a | 要部署的提交 | 要部署的分支或标记（提交时为空） |
例如，您可以在发生 `deployment_status` 事件时运行工作流程。
```yaml
on:
deployment_status
```
{% note %}
**注意：** 当部署状态设置为 `inactive` 时，不会创建 web 挂钩事件。
{% endnote %}
{% ifversion fpt or ghec %}
### `讨论`
在发生 `discussion` 事件的任何时间运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %} For information about the GraphQL API, see "[Discussions]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql/guides/using-the-graphql-api-for-discussions)."
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | ------------ |
| [`讨论`](/webhooks/event-payloads/#discussion) | - `created`<br/>- `edited`<br/>- `deleted`<br/>- `transferred`<br/>- `pinned`<br/>- `unpinned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `locked`<br/>- `unlocked`<br/>- `category_changed`<br/> - `answered`<br/> - `unanswered` | 默认分支上的最新提交 | 默认分支 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在讨论为 `created`、`edited` 或 `answered` 时运行工作流程。
```yaml
on:
discussion:
types: [created, edited, answered]
```
### `discussion_comment`
在发生 `discussion_comment` 事件的任何时间运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %} For information about the GraphQL API, see "[Discussions]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql/guides/using-the-graphql-api-for-discussions)."
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- | ------------ | ------------ |
| [`discussion_comment`](/developers/webhooks-and-events/webhook-events-and-payloads#discussion_comment) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | 默认分支上的最新提交 | 默认分支 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在议题评论为 `created` 或 `deleted` 时运行工作流程。
```yaml
on:
discussion_comment:
types: [created, deleted]
```
{% endif %}
### `复刻`
每当有人复刻仓库（触发 `fork` 事件）时运行您的工作流程。 有关 REST API 的信息，请参阅“[创建复刻](/rest/reference/repos#create-a-fork)”。
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------- | ---- | ------------ | ------------ |
| [`复刻`](/webhooks/event-payloads/#fork) | n/a | 默认分支上的最新提交 | 默认分支 |
例如，您可以在发生 `fork` 事件时运行工作流程。
```yaml
on:
fork
```
### `gollum`
当有人创建或更新 Wiki 页面时（触发 `gollum` 事件）运行您的工作流程。
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------- | ---- | ------------ | ------------ |
| [`gollum`](/webhooks/event-payloads/#gollum) | n/a | 默认分支上的最新提交 | 默认分支 |
例如，您可以在发生 `gollum` 事件时运行工作流程。
```yaml
on:
gollum
```
### `issue_comment`
在发生 `issue_comment` 事件的任何时间运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %}有关 REST API 的信息，请参阅“[议题评论](/developers/webhooks-and-events/webhook-events-and-payloads#issue_comment)”。
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | ------------ | ------------ |
| [`issue_comment`](/developers/webhooks-and-events/webhook-events-and-payloads#issue_comment) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | 默认分支上的最新提交 | 默认分支 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在议题评论为 `created` 或 `deleted` 时运行工作流程。
```yaml
on:
issue_comment:
types: [created, deleted]
```
`issue_comment` 事件在评论问题和拉取请求时发生。 要确定 `issue_comment` 事件是否从议题或拉取请求触发，可以检查 `issue.pull_request` 属性的事件有效负载，并使用它作为跳过作业的条件。
例如，您可以选择在拉取请求中发生评论事件时运行 `pr_commented` 作业，在议题中发生评论事件时运行 `issue_commented` 作业。
{% raw %}
```yaml
on: issue_comment
jobs:
pr_commented:
# This job only runs for pull request comments
name: PR comment
if: ${{ github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo "Comment on PR #${{ github.event.issue.number }}"
issue_commented:
# This job only runs for issue comments
name: Issue comment
if: ${{ !github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo "Comment on issue #${{ github.event.issue.number }}"
```
{% endraw %}
### `议题`
在发生 `issues` 事件的任何时间运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %}有关 REST API 的信息，请参阅“[议题](/rest/reference/issues)”。
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | ------------ |
| [`议题`](/webhooks/event-payloads/#issues) | - `opened`<br/>- `edited`<br/>- `deleted`<br/>- `transferred`<br/>- `pinned`<br/>- `unpinned`<br/>- `closed`<br/>- `reopened`<br/>- `assigned`<br/>- `unassigned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `locked`<br/>- `unlocked`<br/>- `milestoned`<br/> - `demilestoned` | 默认分支上的最新提交 | 默认分支 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在议题为 `opened`、`edited` 或 `milestoned` 时运行工作流程。
```yaml
on:
issues:
types: [opened, edited, milestoned]
```
### `标签`
在发生 `label` 事件的任何时间运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %}有关 REST API 的信息，请参阅“[标签](/rest/reference/issues#labels)”。
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------- | ----------------------------------------------------------------- | ------------ | ------------ |
| [`标签`](/webhooks/event-payloads/#label) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | 默认分支上的最新提交 | 默认分支 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在标签为 `created` 或 `deleted` 时运行工作流程。
```yaml
on:
label:
types: [created, deleted]
```
### `里程碑`
在发生 `milestone` 事件的任何时间运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %}有关 REST API 的信息，请参阅“[里程碑](/rest/reference/issues#milestones)”。
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ------------ | ------------ |
| [`里程碑`](/webhooks/event-payloads/#milestone) | - `created`<br/>- `closed`<br/>- `opened`<br/>- `edited`<br/>- `deleted`<br/> | 默认分支上的最新提交 | 默认分支 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在里程碑为 `opened` 或 `deleted` 时运行工作流程。
```yaml
on:
milestone:
types: [opened, deleted]
```
### `page_build`
在有人推送到启用 {% data variables.product.product_name %} Pages 的分支（触发 `page_build` 事件）的任何时间运行您的工作流程。 有关 REST API 的信息，请参阅“[页面](/rest/reference/repos#pages)”。
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------- | ---- | ------------ | ------------ |
| [`page_build`](/webhooks/event-payloads/#page_build) | n/a | 默认分支上的最新提交 | n/a |
例如，您可以在发生 `page_build` 事件时运行工作流程。
```yaml
on:
page_build
```
### `project`
在发生 `project` 事件的任何时间运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %}有关 REST API 的信息，请参阅“[项目](/rest/reference/projects)”。
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ------------ | ------------ |
| [`project`](/webhooks/event-payloads/#project) | - `created`<br/>- `updated`<br/>- `closed`<br/>- `reopened`<br/>- `edited`<br/>- `deleted`<br/> | 默认分支上的最新提交 | 默认分支 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在项目为 `created` 或 `deleted` 时运行工作流程。
```yaml
on:
project:
types: [created, deleted]
```
### `project_card`
在发生 `project_card` 事件的任何时间运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %}有关 REST API 的信息，请参阅“[项目卡](/rest/reference/projects#cards)”。
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ------------ | ------------ |
| [`project_card`](/webhooks/event-payloads/#project_card) | - `created`<br/>- `moved`<br/>- `converted` to an issue<br/>- `edited`<br/>- `deleted` | 默认分支上的最新提交 | 默认分支 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在项目卡为 `opened` 或 `deleted` 时运行工作流程。
```yaml
on:
project_card:
types: [created, deleted]
```
### `project_column`
在发生 `project_column` 事件的任何时间运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %}有关 REST API 的信息，请参阅“[项目列](/rest/reference/projects#columns)”。
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------ | --------------------------------------------------------------------------- | ------------ | ------------ |
| [`project_column`](/webhooks/event-payloads/#project_column) | - `created`<br/>- `updated`<br/>- `moved`<br/>- `deleted` | 默认分支上的最新提交 | 默认分支 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在项目列为 `created` 或 `deleted` 时运行工作流程。
```yaml
on:
project_column:
types: [created, deleted]
```
### `public`
每当有人将私有仓库公开（触发 `public` 事件）时运行您的工作流程。 有关 REST API 的信息，请参阅“[编辑仓库](/rest/reference/repos#edit)”。
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------- | ---- | ------------ | ------------ |
| [`public`](/webhooks/event-payloads/#public) | n/a | 默认分支上的最新提交 | 默认分支 |
例如，您可以在发生 `public` 事件时运行工作流程。
```yaml
on:
public
```
### `pull_request`
在发生 `pull_request` 事件的任何时间运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %}有关 REST API 的信息，请参阅“[拉取请求](/rest/reference/pulls)”。
{% note %}
**注意：**
- 默认情况下，工作流程仅在 `pull_request` 的活动类型为 `opened`、`synchronize` 或 `reopened` 时运行。 要让更多活动类型触发工作流程，请使用 `types` 关键词。
- 如果拉取请求具有合并冲突，工作流程将不会在 `pull_request` 活动上运行。 必须先解决合并冲突。
{% endnote %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | ----------------------------------- |
| [`pull_request`](/webhooks/event-payloads/#pull_request) | - `assigned`<br/>- `unassigned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `opened`<br/>- `edited`<br/>- `closed`<br/>- `reopened`<br/>- `synchronize`<br/>- `converted_to_draft`<br/>- `ready_for_review`<br/>- `locked`<br/>- `unlocked` <br/>- `review_requested` <br/>- `review_request_removed`{% ifversion fpt or ghes > 3.0 or ghae or ghec %} <br/>- `auto_merge_enabled` <br/>- `auto_merge_disabled`{% endif %} | `GITHUB_REF` 分支上的最新合并提交 | PR 合并分支 `refs/pull/:prNumber/merge` |
您可以使用 `types` 关键词扩展或限制默认活动类型。 更多信息请参阅“[{% data variables.product.prodname_actions %} 的工作流程语法](/articles/workflow-syntax-for-github-actions#onevent_nametypes)”。
例如，您可以在拉取请求为 `assigned`、`opened`、`synchronize` 或 `reopened` 时运行工作流程。
```yaml
on:
pull_request:
types: [assigned, opened, synchronize, reopened]
```
{% data reusables.developer-site.pull_request_forked_repos_link %}
### `pull_request_review`
在发生 `pull_request_review` 事件的任何时间运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %}有关 REST API 的信息，请参阅“[拉取请求审查](/rest/reference/pulls#reviews)”。
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------- | ---------------------------------------------------------- | ----------------------- | ----------------------------------- |
| [`pull_request_review`](/webhooks/event-payloads/#pull_request_review) | - `submitted`<br/>- `edited`<br/>- `dismissed` | `GITHUB_REF` 分支上的最新合并提交 | PR 合并分支 `refs/pull/:prNumber/merge` |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在拉取请求审查为 `edited` 或 `dismissed` 时运行工作流程。
```yaml
on:
pull_request_review:
types: [edited, dismissed]
```
{% data reusables.developer-site.pull_request_forked_repos_link %}
### `pull_request_review_comment`
每当拉取请求统一差异的评论被修改（触发 `pull_request_review_comment` 事件）时运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %} 有关 REST API 的信息，请参阅“[审查评论](/rest/reference/pulls#comments)”。
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------------------------------------- | ------------------------------------------------------ | ----------------------- | ----------------------------------- |
| [`pull_request_review_comment`](/webhooks/event-payloads/#pull_request_review_comment) | - `created`<br/>- `edited`<br/>- `deleted` | `GITHUB_REF` 分支上的最新合并提交 | PR 合并分支 `refs/pull/:prNumber/merge` |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在拉取请求审查评论为 `created` 或 `deleted` 时运行工作流程。
```yaml
on:
pull_request_review_comment:
types: [created, deleted]
```
{% data reusables.developer-site.pull_request_forked_repos_link %}
### `pull_request_target`
此事件在拉取请求基础的上下文中运行，而不是像 `pull_request` 事件一样在合并提交中运行。 这样可以防止从拉取请求的头部执行不安全的工作流程代码，以免更改您的仓库或窃取您在工作流程中使用的任何机密。 此事件允许您根据事件有效负载的内容创建工作流程来标识和评论拉取请求，等等。
{% warning %}
**警告：** `pull_request_target` 事件被授予读/写仓库令牌，可以访问机密，即使从复刻触发时。 虽然工作流程在拉取请求的基础上下文中运行，但您应该确保不在此事件中检出、生成或运行来自拉取请求的不受信任代码。 此外，任何缓存共享与基本分支相同的范围，并且为了帮助防止缓存中毒，如果缓存内容可能已更改，则不应保存缓存。 更多信息请参阅 GitHub 安全实验室网站上的“[保持 GitHub Actions 和工作流程安全：阻止 pwn 请求](https://securitylab.github.com/research/github-actions-preventing-pwn-requests)”。
{% endwarning %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | ------------ |
| [`pull_request_target`](/webhooks/event-payloads/#pull_request) | - `assigned`<br/>- `unassigned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `opened`<br/>- `edited`<br/>- `closed`<br/>- `reopened`<br/>- `synchronize`<br/>- `converted_to_draft`<br/>- `ready_for_review`<br/>- `locked`<br/>- `unlocked` <br/>- `review_requested` <br/>- `review_request_removed`{% ifversion fpt or ghes > 3.0 or ghae or ghec %} <br/>- `auto_merge_enabled` <br/>- `auto_merge_disabled`{% endif %} | PR 基分支上的最后一次提交 | PR 基础分支 |
默认情况下，工作流程仅在 `pull_request_target` 的活动类型为 `opened`、`synchronize` 或 `reopened` 时运行。 要让更多活动类型触发工作流程，请使用 `types` 关键词。 更多信息请参阅“[{% data variables.product.prodname_actions %} 的工作流程语法](/articles/workflow-syntax-for-github-actions#onevent_nametypes)”。
例如，您可以在拉取请求为 `assigned`、`opened`、`synchronize` 或 `reopened` 时运行工作流程。
```yaml
on:
pull_request_target:
types: [assigned, opened, synchronize, reopened]
```
### `推送`
{% note %}
**注：**适用于 GitHub Actions 的 web 挂钩有效负载在 `commit` 对象中不包括 `added`、`removed` 和 `modified` 属性。 您可以使用 REST API 检索完整的提交对象。 更多信息请参阅“[获取提交](/rest/reference/commits#get-a-commit)”。
{% endnote %}
有人向仓库分支推送（触发 `push` 事件）时运行您的工作流程。
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------- | ---- | ---------------------- | ------------ |
| [`推送`](/webhooks/event-payloads/#push) | n/a | 推送的提交，除非删除分支（当它是默认分支时） | 更新的引用 |
例如，您可以在发生 `push` 事件时运行工作流程。
```yaml
on:
push
```
### `registry_package`
只要软件包为 `published` or `updated`，即运行工作流程。 更多信息请参阅“[使用 {% data variables.product.prodname_registry %} 管理包](/github/managing-packages-with-github-packages)”。
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------- | ----------------------------------- | ------------------------------- | ------------ |
| [`registry_package`](/webhooks/event-payloads/#package) | - `published`<br/>- `updated` | Commit of the published package | 已发布软件包的分支或标签 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在软件包为 `published` 时运行工作流程。
```yaml
on:
registry_package:
types: [published]
```
### `发行版`
{% note %}
**注意：**对草稿发行版不触发 `release` 事件。
{% endnote %}
在发生 `release` 事件的任何时间运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %}有关 REST API 的信息，请参阅“[发行版](/rest/reference/repos#releases)”。
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | ------------ |
| [`发行版`](/webhooks/event-payloads/#release) | - `published` <br/>- `unpublished` <br/>- `created` <br/>- `edited` <br/>- `deleted` <br/>- `prereleased`<br/> - `released` | 标记的发行版中的最新提交 | 发行版标记 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在版本发布为 `published` 时运行工作流程。
```yaml
on:
release:
types: [published]
```
{% note %}
**注意：**`prereleased` 类型不会触发从草稿版本预发布，但 `published` 类型会触发。 如果您希望工作流程在稳定*和*预发布时运行，请订阅 `published` 而不是 `released` 和 `prereleased`。
{% endnote %}
### `状态`
在 Git 提交的状态发生变化（触发 `status` 事件）的任何时间运行您的工作流程。 有关 REST API 的信息，请参阅“[状态](/rest/reference/repos#statuses)”。
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------- | ---- | ------------ | ------------ |
| [`状态`](/webhooks/event-payloads/#status) | n/a | 默认分支上的最新提交 | n/a |
例如，您可以在发生 `status` 事件时运行工作流程。
```yaml
on:
status
```
### `查看`
在发生 `watch` 事件的任何时间运行您的工作流程。 {% data reusables.developer-site.multiple_activity_types %}有关 REST API 的信息，请参阅“[星标](/rest/reference/activity#starring)”。
{% data reusables.github-actions.branch-requirement %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------- | ----------- | ------------ | ------------ |
| [`查看`](/webhooks/event-payloads/#watch) | - `started` | 默认分支上的最新提交 | 默认分支 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
例如，您可以在某人为仓库加星标时（即触发关注事件的 `started` 活动类型）运行工作流程。
```yaml
on:
watch:
types: [started]
```
### `workflow_run`
{% data reusables.webhooks.workflow_run_desc %}
{% note %}
**注意：**
* This event will only trigger a workflow run if the workflow file is on the default branch.
* You can't use `workflow_run` to chain together more than three levels of workflows. For example, if you attempt to trigger five workflows (named `B` to `F`) to run sequentially after an initial workflow `A` has run (that is: `A` → `B` → `C` → `D` → `E` → `F`), workflows `E` and `F` will not be run.
{% endnote %}
| Web 挂钩事件有效负载 | 活动类型 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------- | ------------------------------------- | ------------ | ------------ |
| [`workflow_run`](/webhooks/event-payloads/#workflow_run) | - `completed`<br/>- `requested` | 默认分支上的最新提交 | 默认分支 |
{% data reusables.developer-site.limit_workflow_to_activity_types %}
如果需要从此事件中筛选分支，可以使用 `branches` 或 `branches-ignore`。
在此示例中，工作流程配置为在单独的“运行测试”工作流程完成后运行。
```yaml
on:
workflow_run:
workflows: ["Run Tests"]
branches: [main]
types:
- completed
- requested
```
要根据上次工作流程运行的结果有条件地运行工作流程作业，您可以使用 [`jobs.<job_id>.if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif) 或 [`jobs.<job_id>.steps[*].if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsif) 有条件地结合上次运行的`结论`。 例如：
```yaml
on:
workflow_run:
workflows: ["Build"]
types: [completed]
jobs:
on-success:
runs-on: ubuntu-latest
if: {% raw %}${{ github.event.workflow_run.conclusion == 'success' }}{% endraw %}
steps:
...
on-failure:
runs-on: ubuntu-latest
if: {% raw %}${{ github.event.workflow_run.conclusion == 'failure' }}{% endraw %}
steps:
...
```
## 使用个人访问令牌触发新工作流程
{% data reusables.github-actions.actions-do-not-trigger-workflows %} 更多信息请参阅“[使用 GITHUB_TOKEN 验证身份](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)”。
如果要从工作流程运行触发工作流程，您可以使用个人访问令牌触发事件。 您需要创建个人访问令牌并将其存储为密码。 为了最大限度地降低 {% data variables.product.prodname_actions %} 使用成本，请确保不要创建递归或意外的工作流程。 有关存储个人访问令牌的更多信息，请参阅“[创建和存储加密密码](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)”。

185
translations/zh-CN/content/actions/learn-github-actions/managing-complex-workflows.md
View File

@@ -1,185 +0,0 @@
---
title: 管理复杂的工作流程
shortTitle: 管理复杂的工作流程
intro: '本指南说明如何使用 {% data variables.product.prodname_actions %} 的高级功能，包括机密管理、相关作业、缓存、生成矩阵、{% ifversion fpt or ghes > 3.0 or ghae or ghec %}环境{% endif %}和标签。'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: how_to
topics:
- Workflows
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## 概览
本文介绍了 {% data variables.product.prodname_actions %} 的一些高级功能，可帮助您创建更复杂的工作流程。
## 存储密码
如果您的工作流程使用敏感数据，例如密码或证书， 您可以将这些信息在 {% data variables.product.prodname_dotcom %} 中保存为 _机密_，然后在工作流中将它们用作环境变量。 这意味着您将能够创建和共享工作流程，而无需直接在 YAML 工作流程中嵌入敏感值。
此示例操作演示如何将现有机密引用为环境变量，并将其作为参数发送到示例命令。
{% raw %}
```yaml
jobs:
example-job:
runs-on: ubuntu-latest
steps:
- name: Retrieve secret
env:
super_secret: ${{ secrets.SUPERSECRET }}
run: |
example-command "$super_secret"
```
{% endraw %}
更多信息请参阅“[创建和存储加密密码](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)”。
## 创建依赖的作业
默认情况下，工作流程中的作业同时并行运行。 因此，如果您有一个作业必须在另一个作业完成后运行，可以使用 `needs` 关键字来创建此依赖项。 如果其中一个作业失败，则跳过所有从属作业；但如果您需要作业继续，可以使用条件语句 [`if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif) 来定义。
在此示例中，`setup`、`build` 和 `test` 作业连续运行，`build` 和 `test` 取决于其前面的作业成功完成：
```yaml
jobs:
setup:
runs-on: ubuntu-latest
steps:
- run: ./setup_server.sh
build:
needs: setup
runs-on: ubuntu-latest
steps:
- run: ./build_server.sh
test:
needs: build
runs-on: ubuntu-latest
steps:
- run: ./test_server.sh
```
更多信息请参阅 [`jobs.<job_id>.needs`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)。
## 使用构建矩阵
如果您希望工作流程跨操作系统、平台和语言的多个组合运行测试，可以使用构建矩阵。 构建矩阵是使用 `strategy` 关键字创建的，它接收构建选项作为数组。 例如，此构建矩阵将使用不同版本的 Node.js 多次运行作业：
{% raw %}
```yaml
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node: [6, 8, 10]
steps:
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node }}
```
{% endraw %}
更多信息请参阅 [`jobs.<job_id>.strategy.matrix`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix)。
{% ifversion fpt or ghec %}
## 缓存依赖项
{% data variables.product.prodname_dotcom %} 托管的运行器启动为每个作业的新环境，如果您的作业定期重复使用依赖项，您可以考虑缓存这些文件以帮助提高性能。 缓存一旦创建，就可用于同一仓库中的所有工作流程。
此示例演示如何缓存 `~/.npm` 目录：
{% raw %}
```yaml
jobs:
example-job:
steps:
- name: Cache node modules
uses: actions/cache@v2
env:
cache-name: cache-node-modules
with:
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
```
{% endraw %}
更多信息请参阅“<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">缓存依赖项以加快工作流程</a>”。
{% endif %}
## 使用数据库和服务容器
如果作业需要数据库或缓存服务，可以使用 [`services`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idservices) 关键字创建临时容器来托管服务；生成的容器然后可用于该作业中的所有步骤，并在作业完成后删除。 此示例演示作业如何使用 `services` 创建 `postgres` 容器，然后使用 `node` 连接到服务。
```yaml
jobs:
container-job:
runs-on: ubuntu-latest
container: node:10.18-jessie
services:
postgres:
image: postgres
steps:
- name: Check out repository code
uses: actions/checkout@v2
- name: Install dependencies
run: npm ci
- name: Connect to PostgreSQL
run: node client.js
env:
POSTGRES_HOST: postgres
POSTGRES_PORT: 5432
```
更多信息请参阅“[使用数据库和服务容器](/actions/configuring-and-managing-workflows/using-databases-and-service-containers)”。
## 使用标签路由工作流程
此功能可帮助您将作业分配到特定的托管运行器。 如果要确保特定类型的运行器处理作业，可以使用标签来控制作业的执行位置。 除了 `self-hosted` 的默认标签之外，您还可以向自托管运行器分配标签。 然后，您可以在 YAML 工作流程中引用这些标签，确保以可预测的方式安排作业。{% ifversion not ghae %} {% data variables.product.prodname_dotcom %} 托管的运行器已指定预定义的标签。{% endif %}
此示例显示工作流程如何使用标签来指定所需的运行器：
```yaml
jobs:
example-job:
runs-on: [self-hosted, linux, x64, gpu]
```
工作流程只能在一个所有标签处于 `runs-on` 数组中的运行器上运行。 作业将优先转到具有指定标签的空闲自托管运行器。 如果没有可用且具有指定标签的 {% data variables.product.prodname_dotcom %} 托管运行器存在，作业将转到 {% data variables.product.prodname_dotcom %} 托管的运行器。
要了解自托管运行器标签的更多信息，请参阅“[将标签与自托管运行器一起使用](/actions/hosting-your-own-runners/using-labels-with-self-hosted-runners)”。
{% ifversion fpt or ghes %}
要详细了解
{% data variables.product.prodname_dotcom %} 托管的运行器标签，请参阅[“支持的运行器和硬件资源”](/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources)。
{% endif %}
{% data reusables.actions.reusable-workflows %}
{% ifversion fpt or ghes > 3.0 or ghae or ghec %}
## 使用环境
您可以使用保护规则和机密配置环境。 工作流程中的每个作业都可以引用单个环境。 在将引用环境的作业发送到运行器之前，必须通过为环境配置的任何保护规则。 更多信息请参阅“[使用环境进行部署](/actions/deployment/using-environments-for-deployment)”。
{% endif %}
## Using starter workflows
{% data reusables.actions.workflow-template-overview %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.actions-tab %}
1. 如果您的仓库已经有工作流程：在左上角单击 **New workflow（新工作流程）**。 ![创建新工作流程](/assets/images/help/repository/actions-new-workflow.png)
1. Under the name of the starter workflow you'd like to use, click **Set up this workflow**. ![设置此工作流程](/assets/images/help/settings/actions-create-starter-workflow.png)
## 后续步骤
要继续了解 {% data variables.product.prodname_actions %}，请参阅“[与组织共享工作流程、秘密和运行器](/actions/learn-github-actions/sharing-workflows-secrets-and-runners-with-your-organization)”。

304
translations/zh-CN/content/actions/learn-github-actions/reusing-workflows.md
View File

@@ -1,304 +0,0 @@
---
title: Reusing workflows
shortTitle: Reusing workflows
intro: Learn how to avoid duplication when creating a workflow by reusing existing workflows.
miniTocMaxHeadingLevel: 3
versions:
fpt: '*'
ghec: '*'
ghes: '>=3.4'
ghae: issue-4757
type: how_to
topics:
- Workflows
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## 概览
Rather than copying and pasting from one workflow to another, you can make workflows reusable. You and anyone with access to the reusable workflow can then call the reusable workflow from another workflow.
Reusing workflows avoids duplication. This makes workflows easier to maintain and allows you to create new workflows more quickly by building on the work of others, just as you do with actions. Workflow reuse also promotes best practice by helping you to use workflows that are well designed, have already been tested, and have been proved to be effective. Your organization can build up a library of reusable workflows that can be centrally maintained.
The diagram below shows three build jobs on the left of the diagram. After each of these jobs completes successfully a dependent job called "Deploy" runs. This job calls a reusable workflow that contains three jobs: "Staging", "Review", and "Production." The "Production" deployment job only runs after the "Staging" job has completed successfully. Using a reusable workflow to run deployment jobs allows you to run those jobs for each build without duplicating code in workflows.
![Diagram of a reusable workflow for deployment](/assets/images/help/images/reusable-workflows-ci-cd.png)
A workflow that uses another workflow is referred to as a "caller" workflow. The reusable workflow is a "called" workflow. One caller workflow can use multiple called workflows. Each called workflow is referenced in a single line. The result is that the caller workflow file may contain just a few lines of YAML, but may perform a large number of tasks when it's run. When you reuse a workflow, the entire called workflow is used, just as if it was part of the caller workflow.
If you reuse a workflow from a different repository, any actions in the called workflow run as if they were part of the caller workflow. For example, if the called workflow uses `actions/checkout`, the action checks out the contents of the repository that hosts the caller workflow, not the called workflow.
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 "[Context and expression syntax for GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)."
### Reusable workflows and starter workflow
Starter workflow allow everyone in your organization who has permission to create workflows to do so more quickly and easily. When people create a new workflow, they can choose a starter workflow and some or all of the work of writing the workflow will be done for them. Inside starter workflow, you can also reference reusable workflows to make it easy for people to benefit from reusing centrally managed workflow code. If you use a tag or branch name when referencing the reusable workflow then you can ensure that everyone who reuses that workflow will always be using the same YAML code. However, if you reference a reusable workflow by a tag or branch, be sure that you can trust that version of the workflow. For more information, see "[Security hardening for {% data variables.product.prodname_actions %}](/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows)."
For more information, see "[Creating starter workflows for your organization](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)."
## Access to reusable workflows
A reusable workflow can be used by another workflow if {% ifversion ghes or ghec or ghae %}any{% else %}either{% endif %} of the following is true:
* Both workflows are in the same repository.
* The called workflow is stored in a public repository.{% ifversion ghes or ghec or ghae %}
* The called workflow is stored in an internal repository and the settings for that repository allow it to be accessed. 更多信息请参阅“[管理仓库的 {% data variables.product.prodname_actions %} 设置](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository)”。{% endif %}
## Using runners
{% ifversion fpt or ghes or ghec %}
### 使用 GitHub 托管的运行器
The assignment of {% data variables.product.prodname_dotcom %}-hosted runners is always evaluated using only the caller's context. Billing for {% data variables.product.prodname_dotcom %}-hosted runners is always associated with the caller. The caller workflow cannot use {% data variables.product.prodname_dotcom %}-hosted runners from the called repository. 更多信息请参阅“[关于 {% data variables.product.prodname_dotcom %} 托管的运行器](/actions/using-github-hosted-runners/about-github-hosted-runners)”。
### Using self-hosted runners
{% endif %}
Called workflows can access self-hosted runners from 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{% ifversion ghes or ghec or ghae %} or enterprise{% endif %}, provided that the runner has been made available to the caller repository
## 限制
* Reusable workflows can't call other reusable workflows.
* Reusable workflows stored within a private repository can only be used by workflows within the same repository.
* 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 about the `env` context, see "[Context and expression syntax for GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#env-context)."
* The `strategy` property is not supported in any job that calls a reusable workflow.
## Creating a reusable workflow
Reusable workflows are YAML-formatted files, very similar to any other workflow file. As with other workflow files, you locate reusable workflows in the `.github/workflows` directory of a repository. Subdirectories of the `workflows` directory are not supported.
For a workflow to be reusable, the values for `on` must include `workflow_call`:
```yaml
on:
workflow_call:
```
### Using inputs and secrets in a reusable workflow
You can define inputs and secrets, which can be passed from the caller workflow and then used within the called workflow. There are three stages to using an input or a secret in a reusable workflow.
1. In the reusable workflow, use the `inputs` and `secrets` keywords to define inputs or secrets that will be passed from a caller workflow.
{% raw %}
```yaml
on:
workflow_call:
inputs:
username:
required: true
type: string
secrets:
envPAT:
required: true
```
{% endraw %}
For details of the syntax for defining inputs and secrets, see [`on.workflow_call.inputs`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callinputs) and [`on.workflow_call.secrets`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callsecrets).
1. Reference the input or secret in the reusable workflow.
{% raw %}
```yaml
jobs:
reusable_workflow_job:
runs-on: ubuntu-latest
environment: production
steps:
- uses: ./.github/actions/my-action@v1
with:
username: ${{ inputs.username }}
token: ${{ secrets.envPAT }}
```
{% endraw %}
In the example above, `envPAT` is an environment secret that's been added to the `production` environment. This environment is therefore referenced within the job.
{% note %}
**Note**: Environment secrets are encrypted strings that are stored in an environment that you've defined for a repository. Environment secrets are only available to workflow jobs that reference the appropriate environment. 更多信息请参阅“[使用环境进行部署](/actions/deployment/targeting-different-environments/using-environments-for-deployment#environment-secrets)”。
{% endnote %}
1. Pass the input or secret from the caller workflow.
{% indented_data_reference reusables.actions.pass-inputs-to-reusable-workflows spaces=3 %}
### Example reusable workflow
This reusable workflow file named `workflow-B.yml` (we'll refer to this later in the [example caller workflow](#example-caller-workflow)) takes an input string and a secret from the caller workflow and uses them in an action.
{% raw %}
```yaml{:copy}
name: Reusable workflow example
on:
workflow_call:
inputs:
username:
required: true
type: string
secrets:
token:
required: true
jobs:
example_job:
name: Pass input and secrets to my-action
runs-on: ubuntu-latest
steps:
- uses: ./.github/actions/my-action@v1
with:
username: ${{ inputs.username }}
token: ${{ secrets.token }}
```
{% endraw %}
## Calling a reusable workflow
You call a reusable workflow by using the `uses` keyword. Unlike when you are using actions within a workflow, you call reusable workflows directly within a job, and not from within job steps.
[`jobs.<job_id>.uses`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_iduses)
You reference reusable workflow files using the syntax:
`{owner}/{repo}/{path}/{filename}@{ref}`
You can call multiple workflows, referencing each in a separate job.
{% data reusables.actions.uses-keyword-example %}
### Passing inputs and secrets to a reusable workflow
{% data reusables.actions.pass-inputs-to-reusable-workflows%}
### 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:
* [`jobs.<job_id>.name`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idname)
* [`jobs.<job_id>.uses`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_iduses)
* [`jobs.<job_id>.with`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idwith)
* [`jobs.<job_id>.with.<input_id>`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idwithinput_id)
* [`jobs.<job_id>.secrets`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsecrets)
* [`jobs.<job_id>.secrets.<secret_id>`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsecretssecret_id)
* [`jobs.<job_id>.needs`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)
* [`jobs.<job_id>.if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif)
* [`jobs.<job_id>.permissions`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idpermissions)
{% 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`. 更多信息请参阅“[工作流程中的身份验证](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)。
* The `GITHUB_TOKEN` permissions passed from the caller workflow can be only downgraded (not elevated) by the called workflow.
{% endnote %}
### Example caller workflow
This workflow file calls two workflow files. The second of these, `workflow-B.yml` (shown in the [example reusable workflow](#example-reusable-workflow)), is passed an input (`username`) and a secret (`token`).
{% raw %}
```yaml{:copy}
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:
uses: octo-org/example-repo/.github/workflows/workflow-B.yml@main
with:
username: mona
secrets:
token: ${{ secrets.TOKEN }}
```
{% endraw %}
## Using outputs from a reusable workflow
A reusable workflow may generate data that you want to use in the caller workflow. To use these outputs, you must specify them as the outputs of the reusable workflow.
The following reusable workflow has a single job containing two steps. In each of these steps we set a single word as the output: "hello" and "world." In the `outputs` section of the job, we map these step outputs to job outputs called: `output1` and `output2`. In the `on.workflow_call.outputs` section we then define two outputs for the workflow itself, one called `firstword` which we map to `output1`, and one called `secondword` which we map to `output2`.
{% raw %}
```yaml{:copy}
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 "::set-output name=firstword::hello"
- id: step2
run: echo "::set-output name=secondword::world"
```
{% endraw %}
We can now use the outputs in the caller workflow, in the same way you would use the outputs from a job within the same workflow. We reference the outputs using the names defined at the workflow level in the reusable workflow: `firstword` and `secondword`. In this workflow, `job1` calls the reusable workflow and `job2` prints the outputs from the reusable workflow ("hello world") to standard output in the workflow log.
{% raw %}
```yaml{:copy}
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 }}
```
{% endraw %}
For more information on using job outputs, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idoutputs)."
## Monitoring which workflows are being used
You can use the {% data variables.product.prodname_dotcom %} REST API to monitor how reusable workflows are being used. The `prepared_workflow_job` audit log action is triggered when a workflow job is started. Included in the data recorded are:
* `repo` - the organization/repository where the workflow job is located. For a job that calls another workflow, this is the organization/repository of the caller workflow.
* `@timestamp` - the date and time that the job was started, in Unix epoch format.
* `job_name` - the name of the job that was run.
* `job_workflow_ref` - the workflow file that was used, in the form `{owner}/{repo}/{path}/{filename}@{ref}`. For a job that calls another workflow, this identifies the called workflow.
For information about using the REST API to query the audit log for an organization, see "[Organizations](/rest/reference/orgs#get-the-audit-log-for-an-organization)."
{% note %}
**Note**: Audit data for `prepared_workflow_job` can only be viewed using the REST API. It is not visible in the {% data variables.product.prodname_dotcom %} web interface, or included in JSON/CSV exported audit data.
{% endnote %}
## 后续步骤
To continue learning about {% data variables.product.prodname_actions %}, see "[Events that trigger workflows](/actions/learn-github-actions/events-that-trigger-workflows)."

54
translations/zh-CN/content/actions/learn-github-actions/sharing-workflows-secrets-and-runners-with-your-organization.md
View File

@@ -1,54 +0,0 @@
---
title: 'Sharing workflows, secrets, and runners with your organization'
shortTitle: 与组织共享工作流程
intro: 'Learn how you can use organization features to collaborate with your team, by sharing starter workflow, secrets, and self-hosted runners.'
redirect_from:
- /actions/learn-github-actions/sharing-workflows-with-your-organization
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: how_to
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## 概览
如果需要与您的团队共享工作流程和其他 {% data variables.product.prodname_actions %} 功能，则考虑在 {% data variables.product.prodname_dotcom %} 组织内协作。 组织允许您集中存储和管理机密、构件和自托管运行器。 You can also create starter workflow in the `.github` repository and share them with other users in your organization.
## Using starter workflows
{% data reusables.actions.workflow-organization-templates %} For more information, see "[Creating starter workflows for your organization](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)."
{% data reusables.actions.reusable-workflows %}
## 在组织内共享机密
您可以在组织内集中管理您的机密，然后将其提供给选定的仓库。 这也意味着您可以在一个位置更新机密，并且将更改应用于使用该机密的所有仓库工作流程。
在组织中创建密码时，可以使用策略来限制可以访问该密码的仓库。 例如，您可以将访问权限授予所有仓库，也可以限制仅私有仓库或指定的仓库列表拥有访问权限。
{% data reusables.github-actions.permissions-statement-secrets-organization %}
{% data reusables.organizations.navigate-to-org %}
{% data reusables.organizations.org_settings %}
{% data reusables.github-actions.sidebar-secret %}
1. 单击 **New secret（新建密码）**。
1. 在 **Name（名称）**输入框中键入密码的名称。
1. 输入密码的 **Value（值）**。
1. 从 **Repository access（仓库访问权限）**下拉列表，选择访问策略。
1. 单击 **Add secret（添加密码）**。
## 在组织内共享自托管运行器
组织管理员可以将其自托管的运行器添加到组，然后创建控制哪些仓库可访问该组的策略。
更多信息请参阅“[使用组管理对自托管运行器的访问](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups)”。
## 后续步骤
To continue learning about {% data variables.product.prodname_actions %}, see "[Creating starter workflows for your organization](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)."

54
translations/zh-CN/content/actions/learn-github-actions/using-starter-workflows.md
View File

@@ -1,54 +0,0 @@
---
title: Using starter workflows
intro: '{% data variables.product.product_name %} provides starter workflows for a variety of languages and tooling.'
redirect_from:
- /articles/setting-up-continuous-integration-using-github-actions
- /github/automating-your-workflow-with-github-actions/setting-up-continuous-integration-using-github-actions
- /actions/automating-your-workflow-with-github-actions/setting-up-continuous-integration-using-github-actions
- /actions/building-and-testing-code-with-continuous-integration/setting-up-continuous-integration-using-github-actions
- /actions/guides/setting-up-continuous-integration-using-workflow-templates
- /actions/learn-github-actions/using-workflow-templates
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- Workflows
- CI
- CD
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## About starter workflows
{% data variables.product.product_name %} offers starter workflows for a variety of languages and tooling. When you set up workflows in your repository, {% data variables.product.product_name %} analyzes the code in your repository and recommends workflows based on the language and framework in your repository. For example, if you use [Node.js](https://nodejs.org/en/), {% data variables.product.product_name %} will suggest a starter workflow file that installs your Node.js packages and runs your tests.{% if actions-starter-template-ui %} You can search and filter to find relevant starter workflows.{% endif %}
You can also create your own starter workflow to share with your organization. These starter workflows will appear alongside the {% data variables.product.product_name %}-provided starter workflows. For more information, see "[Creating starter workflows for your organization](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)."
## Using starter workflows
Anyone with write permission to a repository can set up {% data variables.product.prodname_actions %} starter workflows for CI/CD or other automation.
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.actions-tab %}
1. If you already have a workflow in your repository, click **New workflow**.
1. Find the starter workflow that you want to use, then click **Set up this workflow**.{% if actions-starter-template-ui %} To help you find the starter workflow that you want, you can search for keywords or filter by category.{% endif %}
1. If the starter workflow contains comments detailing additional setup steps, follow these steps. Many of the starter workflow have corresponding guides. For more information, see [the {% data variables.product.prodname_actions %} guides](/actions/guides)."
1. Some starter workflows use secrets. For example, {% raw %}`${{ secrets.npm_token }}`{% endraw %}. If the starter workflow uses a secret, store the value described in the secret name as a secret in your repository. 更多信息请参阅“[加密密码](/actions/reference/encrypted-secrets)”。
1. Optionally, make additional changes. For example, you might want to change the value of `on` to change when the workflow runs.
1. 单击 **Start commit（开始提交）**。
1. Write a commit message and decide whether to commit directly to the default branch or to open a pull request.
## 延伸阅读
- "[关于持续集成](/articles/about-continuous-integration)"
- "[Managing workflow runs](/actions/managing-workflow-runs)"
- "[About monitoring and troubleshooting](/actions/monitoring-and-troubleshooting-workflows/about-monitoring-and-troubleshooting)"
- "[了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)"
{% ifversion fpt or ghec %}
- "[管理 {% data variables.product.prodname_actions %} 的计费](/billing/managing-billing-for-github-actions)"
{% endif %}

413
translations/zh-CN/content/actions/learn-github-actions/workflow-commands-for-github-actions.md
View File

@@ -1,413 +0,0 @@
---
title: GitHub Actions 的工作流程命令
shortTitle: 工作流程命令
intro: 您可以在工作流程或操作代码中运行 shell 命令时使用工作流程命令。
redirect_from:
- /articles/development-tools-for-github-actions
- /github/automating-your-workflow-with-github-actions/development-tools-for-github-actions
- /actions/automating-your-workflow-with-github-actions/development-tools-for-github-actions
- /actions/reference/development-tools-for-github-actions
- /actions/reference/logging-commands-for-github-actions
- /actions/reference/workflow-commands-for-github-actions
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## 关于工作流程命令
操作可以与运行器机器进行通信，以设置环境变量，其他操作使用的输出值，将调试消息添加到输出日志和其他任务。
大多数工作流程命令使用特定格式的 `echo` 命令，而其他工作流程则通过写入文件被调用。 更多信息请参阅“[环境文件](#environment-files)”。
``` bash
echo "::workflow-command parameter1={data},parameter2={data}::{command value}"
```
{% note %}
**注意：**工作流程命令和参数名称不区分大小写。
{% endnote %}
{% warning %}
**警告：**如果您使用命令提示符，则使用工作流程命令时忽略双引号字符 (`"`)。
{% endwarning %}
## 使用工作流程命令访问工具包函数
[actions/toolkit](https://github.com/actions/toolkit) 包括一些可以作为工作流程命令执行的功能。 使用 `::` 语法来运行您的 YAML 文件中的工作流程命令；然后，通过 `stdout` 将这些命令发送给运行器。 例如，不使用代码来设置环境变量，如下所示：
```javascript
core.setOutput('SELECTED_COLOR', 'green');
```
您可以在工作流程中使用 `set-output` 命令来设置相同的值：
{% raw %}
``` yaml
- name: Set selected color
run: echo '::set-output name=SELECTED_COLOR::green'
id: random-color-generator
- name: Get color
run: echo "The selected color is ${{ steps.random-color-generator.outputs.SELECTED_COLOR }}"
```
{% endraw %}
下表显示了在工作流程中可用的工具包功能：
| 工具包函数 | 等效工作流程命令 |
| --------------------- | --------------------------------------------------------------------- |
| `core.addPath` | Accessible using environment file `GITHUB_PATH` |
| `core.debug` | `debug` |{% ifversion fpt or ghes > 3.2 or ghae-issue-4929 or ghec %}
| `core.notice` | `notice`
{% endif %}
| `core.error` | `error` |
| `core.endGroup` | `endgroup` |
| `core.exportVariable` | Accessible using environment file `GITHUB_ENV` |
| `core.getInput` | 可使用环境变量 `INPUT_{NAME}` 访问 |
| `core.getState` | 可使用环境变量 `STATE_{NAME}` 访问 |
| `core.isDebug` | 可使用环境变量 `RUNNER_DEBUG` 访问 |
| `core.saveState` | `save-state` |
| `core.setCommandEcho` | `echo` |
| `core.setFailed` | 用作 `::error` 和 `exit 1` 的快捷方式 |
| `core.setOutput` | `set-output` |
| `core.setSecret` | `add-mask` |
| `core.startGroup` | `组` |
| `core.warning` | `警告` |
## 设置输出参数
```
::set-output name={name}::{value}
```
设置操作的输出参数。
（可选）您也可以在操作的元数据文件中声明输出参数。 更多信息请参阅“[{% data variables.product.prodname_actions %} 的元数据语法](/articles/metadata-syntax-for-github-actions#outputs)”。
### 示例
``` bash
echo "::set-output name=action_fruit::strawberry"
```
## 设置调试消息
```
::debug::{message}
```
将调试消息打印到日志。 您可以创建名为 `ACTIONS_STEP_DEBUG`、值为 `true` 的密码，才能在日志中查看通过此命令设置的调试消息。 更多信息请参阅“[启用调试日志记录](/actions/managing-workflow-runs/enabling-debug-logging)”。
### 示例
``` bash
echo "::debug::Set the Octocat variable"
```
{% ifversion fpt or ghes > 3.2 or ghae-issue-4929 or ghec %}
## 设置通知消息
```
::notice file={name},line={line},endLine={endLine},title={title}::{message}
```
创建通知消息并将该消息打印到日志。 {% data reusables.actions.message-annotation-explanation %}
{% data reusables.actions.message-parameters %}
### 示例
``` bash
echo "::notice file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
```
{% endif %}
## 设置警告消息
```
::warning file={name},line={line},endLine={endLine},title={title}::{message}
```
创建警告消息并将该消息打印到日志。 {% data reusables.actions.message-annotation-explanation %}
{% data reusables.actions.message-parameters %}
### 示例
``` bash
echo "::warning file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
```
## 设置错误消息
```
::error file={name},line={line},endLine={endLine},title={title}::{message}
```
创建错误消息并将该消息打印到日志。 {% data reusables.actions.message-annotation-explanation %}
{% data reusables.actions.message-parameters %}
### 示例
``` bash
echo "::error file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
```
## 对日志行分组
```
::group::{title}
::endgroup::
```
在日志中创建一个可扩展的组。 要创建组，请使用 `group` 命令并指定 `title`。 打印到 `group` 与 `endgroup` 命令之间日志的任何内容都会嵌套在日志中可扩展的条目内。
### 示例
```bash
echo "::group::My title"
echo "Inside group"
echo "::endgroup::"
```
![工作流运行日志中的可折叠组](/assets/images/actions-log-group.png)
## 在日志中屏蔽值
```
::add-mask::{value}
```
屏蔽值可阻止在日志中打印字符串或变量。 用空格分隔的每个屏蔽的词均替换为 `*` 字符。 您可以使用环境变量或字符串作为屏蔽的 `value`。
### 屏蔽字符串的示例
当您在日志中打印 `"Mona The Octocat"` 时，您将看到 `"***"`。
```bash
echo "::add-mask::Mona The Octocat"
```
### 屏蔽环境变量的示例
当您在日志中打印变量 `MY_NAME` 或值 `"Mona The Octocat"` 时，您将看到 `"***"` 而不是 `"Mona The Octocat"`。
```bash
MY_NAME="Mona The Octocat"
echo "::add-mask::$MY_NAME"
```
## 停止和启动工作流程命令
`::stop-commands::{endtoken}`
停止处理任何工作流程命令。 此特殊命令可让您记录任何内容而不会意外运行工作流程命令。 例如，您可以停止记录以输出带有注释的整个脚本。
要停止处理工作流程命令，请将唯一的令牌传递给 `stop-commands`。 要继续处理工作流程命令，请传递用于停止工作流程命令的同一令牌。
{% warning %}
**警告：** 请确保您使用的令牌是随机生成的，且对每次运行唯一。 如下面的示例所示，您可以为每次运行生成 `github.token` 的唯一哈希值。
{% endwarning %}
```
::{endtoken}::
```
### 停止和启动工作流程命令的示例
{% raw %}
```yaml
jobs:
workflow-command-job:
runs-on: ubuntu-latest
steps:
- name: disable workflow commands
run: |
echo '::warning:: this is a warning'
echo "::stop-commands::`echo -n ${{ github.token }} | sha256sum | head -c 64`"
echo '::warning:: this will NOT be a warning'
echo "::`echo -n ${{ github.token }} | sha256sum | head -c 64`::"
echo '::warning:: this is a warning again'
```
{% endraw %}
## Echoing command outputs
```
::echo::on
::echo::off
```
Enables or disables echoing of workflow commands. For example, if you use the `set-output` command in a workflow, it sets an output parameter but the workflow run's log does not show the command itself. If you enable command echoing, then the log shows the command, such as `::set-output name={name}::{value}`.
Command echoing is disabled by default. However, a workflow command is echoed if there are any errors processing the command.
The `add-mask`, `debug`, `warning`, and `error` commands do not support echoing because their outputs are already echoed to the log.
You can also enable command echoing globally by turning on step debug logging using the `ACTIONS_STEP_DEBUG` secret. For more information, see "[Enabling debug logging](/actions/managing-workflow-runs/enabling-debug-logging)". In contrast, the `echo` workflow command lets you enable command echoing at a more granular level, rather than enabling it for every workflow in a repository.
### Example toggling command echoing
```yaml
jobs:
workflow-command-job:
runs-on: ubuntu-latest
steps:
- name: toggle workflow command echoing
run: |
echo '::set-output name=action_echo::disabled'
echo '::echo::on'
echo '::set-output name=action_echo::enabled'
echo '::echo::off'
echo '::set-output name=action_echo::disabled'
```
The step above prints the following lines to the log:
```
::set-output name=action_echo::enabled
::echo::off
```
Only the second `set-output` and `echo` workflow commands are included in the log because command echoing was only enabled when they were run. Even though it is not always echoed, the output parameter is set in all cases.
## 将值发送到 pre 和 post 操作
您可以使用 `save-state` 命令来创建环境变量，以便与工作流程的 `pre:` 或 `post:` 操作共享。 例如，您可以使用 `pre:` 操作创建文件，将该文件位置传给 `main:` 操作，然后使用 `post:` 操作删除文件。 或者，您可以使用 `main:` 操作创建文件，将该文件位置传给 `post:` 操作，然后使用 `post:` 操作删除文件。
如果您有多个 `pre:` 或 `post:` 操作，则只能访问使用了 `save-state` 的操作中的已保存值。 有关 `post:` 操作的更多信息，请参阅“[{% data variables.product.prodname_actions %} 的元数据语法](/actions/creating-actions/metadata-syntax-for-github-actions#post)”。
`save-state` 命令只能在操作内运行，并且对 YAML 文件不可用。 保存的值将作为环境值存储，带 `STATE_` 前缀。
此示例使用 JavaScript 运行 `save-state` 命令。 由此生成的环境变量被命名为 `STATE_processID`，带 `12345` 的值：
``` javascript
console.log('::save-state name=processID::12345')
```
然后，`STATE_processID` 变量将仅可被用于 `main` 操作下运行的清理脚本。 此示例在 `main` 中运行，并使用 JavaScript 显示分配给 `STATE_processID` 环境变量的值：
``` javascript
console.log("The running PID from the main action is: " + process.env.STATE_processID);
```
## 环境文件
在工作流程执行期间，运行器生成可用于执行某些操作的临时文件。 这些文件的路径通过环境变量显示。 写入这些文件时，您需要使用 UTF-8 编码，以确保正确处理命令。 多个命令可以写入同一个文件，用换行符分隔。
{% warning %}
**Warning:** On Windows, legacy PowerShell (`shell: powershell`) does not use UTF-8 by default. 请确保使用正确的编码写入文件。 例如，在设置路径时需要设置 UTF-8 编码：
```yaml
jobs:
legacy-powershell-example:
uses: windows-2019
steps:
- shell: powershell
run: echo "mypath" | Out-File -FilePath $env:GITHUB_PATH -Encoding utf8 -Append
```
Or switch to PowerShell Core, which defaults to UTF-8:
```yaml
jobs:
modern-pwsh-example:
uses: windows-2019
steps:
- shell: pwsh
run: echo "mypath" | Out-File -FilePath $env:GITHUB_PATH -Append # no need for -Encoding utf8
```
More detail about UTF-8 and PowerShell Core found on this great [Stack Overflow answer](https://stackoverflow.com/a/40098904/162694):
> ### Optional reading: The cross-platform perspective: PowerShell _Core_:
>
> [PowerShell is now cross-platform](https://blogs.msdn.microsoft.com/powershell/2016/08/18/powershell-on-linux-and-open-source-2/), via its **[PowerShell _Core_](https://github.com/PowerShell/PowerShell)** edition, whose encoding - sensibly - ***defaults to ***BOM-less UTF-8******, in line with Unix-like platforms.
{% endwarning %}
## 设置环境变量
``` bash
echo "{name}={value}" >> $GITHUB_ENV
```
为作业中接下来运行的任何步骤创建或更新环境变量。 创建或更新环境变量的步骤无法访问新值，但在作业中的所有后续步骤均可访问。 环境变量区分大小写，并且可以包含标点符号。
{% note %}
**Note:** Environment variables must be explicitly referenced using the [`env` context](/actions/reference/context-and-expression-syntax-for-github-actions#env-context) in expression syntax or through use of the `$GITHUB_ENV` file directly; environment variables are not implicitly available in shell commands.
{% endnote %}
### 示例
{% raw %}
```
steps:
- name: Set the value
id: step_one
run: |
echo "action_state=yellow" >> $GITHUB_ENV
- name: Use the value
id: step_two
run: |
echo "${{ env.action_state }}" # This will output 'yellow'
```
{% endraw %}
### 多行字符串
对于多行字符串，您可以使用具有以下语法的分隔符。
```
{name}<<{delimiter}
{value}
{delimiter}
```
#### 示例
在此示例中， 我们使用 `EOF` 作为分隔符，并将 `JSON_RESPONSE` 环境变量设置为 cURL 响应的值。
```yaml
steps:
- name: Set the value
id: step_one
run: |
echo 'JSON_RESPONSE<<EOF' >> $GITHUB_ENV
curl https://httpbin.org/json >> $GITHUB_ENV
echo 'EOF' >> $GITHUB_ENV
```
## 添加系统路径
``` bash
echo "{path}" >> $GITHUB_PATH
```
Prepends a directory to the system `PATH` variable and automatically makes it available to all subsequent actions in the current job; the currently running action cannot access the updated path variable. 要查看作业的当前定义路径，您可以在步骤或操作中使用 `echo "$PATH"`。
### 示例
此示例演示如何将用户 `$HOME/.local/bin` 目录添加到 `PATH`：
``` bash
echo "$HOME/.local/bin" >> $GITHUB_PATH
```

1579
translations/zh-CN/content/actions/learn-github-actions/workflow-syntax-for-github-actions.md
View File

File diff suppressed because it is too large Load Diff