Observação: no momento, não há suporte para os executores hospedados no GitHub no GitHub Enterprise Server. Você pode ver mais informações sobre o suporte futuro planejado no GitHub public roadmap.
About workflow triggers
Os acionadores de fluxo de trabalho são eventos que fazem com que um fluxo de trabalho seja executado. Esses eventos podem ser:
- Eventos que ocorrem no repositório do fluxo de trabalho
- Eventos que ocorrem fora do GitHub Enterprise Server e que disparam um evento
repository_dispatch
no GitHub Enterprise Server - Horários agendados
- Manual
Por exemplo, você pode configurar o fluxo de trabalho para executar quando um push é feito no branch padrão do seu repositório, quando uma versão é criada, ou quando um problema é aberto.
Workflow triggers are defined with the on
key. For more information, see "Workflow syntax for GitHub Actions."
The following steps occur to trigger a workflow run:
-
An event occurs on your repository. The event has an associated commit SHA and Git ref.
-
GitHub Enterprise Server searches the
.github/workflows
directory in your repository for workflow files that are present in the associated commit SHA or Git ref of the event. -
A workflow run is triggered for any workflows that have
on:
values that match the triggering event. Some events also require the workflow file to be present on the default branch of the repository in order to run.Each workflow run will use the version of the workflow that is present in the associated commit SHA or Git ref of the event. When a workflow runs, GitHub Enterprise Server sets the
GITHUB_SHA
(commit SHA) andGITHUB_REF
(Git ref) environment variables in the runner environment. For more information, see "Using environment variables."
Triggering a workflow from a workflow
When you use the repository's GITHUB_TOKEN
to perform tasks, events triggered by the GITHUB_TOKEN
will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository's GITHUB_TOKEN
, a new workflow will not run even when the repository contains a workflow configured to run when push
events occur. For more information, see "Authenticating with the GITHUB_TOKEN."
If you do want to trigger a workflow from within a workflow run, you can use a personal access token instead of GITHUB_TOKEN
to trigger events that require a token. You'll need to create a personal access token and store it as a secret. To minimize your GitHub Actions usage costs, ensure that you don't create recursive or unintended workflow runs. For more information about creating a personal access token, see "Creating a personal access token." For more information about storing a personal access token as a secret, see "Creating and storing encrypted secrets."
For example, the following workflow uses a personal access token (stored as a secret called MY_TOKEN
) to add a label to an issue via GitHub CLI. Any workflows that run when a label is added will run once this step is performed.
on:
issues:
types:
- opened
jobs:
label_issue:
runs-on: ubuntu-latest
steps:
- env:
GITHUB_TOKEN: ${{ secrets.MY_TOKEN }}
ISSUE_URL: ${{ github.event.issue.html_url }}
run: |
gh issue edit $ISSUE_URL --add-label "triage"
Conversely, the following workflow uses GITHUB_TOKEN
to add a label to an issue. It will not trigger any workflows that run when a label is added.
on:
issues:
types:
- opened
jobs:
label_issue:
runs-on: ubuntu-latest
steps:
- env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
ISSUE_URL: ${{ github.event.issue.html_url }}
run: |
gh issue edit $ISSUE_URL --add-label "triage"
Using events to trigger workflows
Use the on
key to specify what events trigger your workflow. For more information about events you can use, see "Events that trigger workflows."
Using a single event
Por exemplo, um fluxo de trabalho com o seguinte valor on
será executado quando um push for feito em qualquer branch no repositório do fluxo de trabalho:
on: push
Using multiple events
É possível especificar um único evento ou vários eventos. Por exemplo, um fluxo de trabalho com o valor on
a seguir será executado quando um push for feito em qualquer branch no repositório ou quando alguém criar um fork do repositório:
on: [push, fork]
Se você especificar vários eventos, apenas um desses eventos deverá ocorrer para acionar seu fluxo de trabalho. Se vários eventos de acionamento para o seu fluxo de trabalho ocorrerem ao mesmo tempo, várias execuções de fluxo de trabalho serão acionadas.
Using activity types and filters with multiple events
You can use activity types and filters to further control when your workflow will run. For more information, see Using event activity types and Using filters. Se você especificar tipos de atividade ou filtros para um evento e seu fluxo de trabalho for acionado em vários eventos, você deverá configurar cada evento separadamente. Você deve acrescentar dois-pontos (:
) a todos os eventos, incluindo eventos sem configuração.
Por exemplo, um fluxo de trabalho com o seguinte valor on
será executado quando:
- Uma etiqueta foi criada
- Um push for feito para o branch
main
no repositório - Um push é feito para um branch habilitado para GitHub Pages
on:
label:
types:
- created
push:
branches:
- main
page_build:
Using event activity types
Alguns eventos têm tipos de atividade que oferecem mais controle sobre quando o fluxo de trabalho deve ser executado. Use on.<event_name>.types
para definir o tipo de atividade de evento que vai disparar uma execução de fluxo de trabalho.
Por exemplo, o evento issue_comment
tem os tipos de atividades created
, edited
e deleted
. Se o fluxo de trabalho for disparado no evento label
, ele será executado sempre que um rótulo for criado, editado ou excluído. Se você especificar o tipo de atividade created
para o evento label
, o fluxo de trabalho será executado quando um rótulo for criado, mas não quando um rótulo for editado ou excluído.
on:
label:
types:
- created
Se você especificar vários tipos de atividades, apenas um desses tipos de atividade deverá ocorrer para acionar o fluxo de trabalho. Se vários tipos de atividade do evento de acionamento ocorrer em seu fluxo de trabalho ao mesmo tempo, várias execuções de fluxo de trabalho serão acionadas. Por exemplo, os acionadores de fluxo de trabalho a seguir quando um problema é aberto ou identificado. Se um problema com duas etiquetas for aberta, serão iniciadas três execuções de fluxos de trabalho: uma para o problema aberto e duas para os dois problemas etiquetados.
on:
issues:
types:
- opened
- labeled
Para obter mais informações sobre cada evento e os respectivos tipos de atividades, confira "Eventos que disparam fluxos de trabalho".
Using filters
Alguns eventos têm filtros que dão mais controle sobre quando seu fluxo de trabalho deve ser executado.
Por exemplo, o evento push
tem um filtro branches
que faz com que seu fluxo de trabalho seja executado somente quando ocorrer um push para um branch que corresponde ao filtro branches
, em vez de quando ocorrer qualquer push.
on:
push:
branches:
- main
- 'releases/**'
Using filters to target specific branches for pull request events
Ao usar os eventos pull_request
e pull_request_target
, você pode configurar um fluxo de trabalho para ser executado somente para solicitações de pull direcionadas a branches específicos.
Use o filtro branches
quando quiser incluir padrões de nomes de branches ou quando quiser incluir e excluir padrões de nomes de branches. Use o filtro branches-ignore
quando quiser excluir apenas padrões de nomes de branches. Não é possível usar os filtros branches
e branches-ignore
para o mesmo evento em um fluxo de trabalho.
Se você definir branches
/branches-ignore
e paths
, o fluxo de trabalho só será executado quando ambos os filtros forem atendidos.
As palavras-chave branches
e branches-ignore
aceitam padrões glob que usam caracteres como *
, **
, +
, ?
, !
e outros para corresponder a mais de um nome de branch. Se um nome contiver um desses caracteres e você quiser ter uma correspondência literal, faça escape de cada um desses caracteres especiais com \
. Para obter mais informações sobre padrões glob, confira a "Folha de referências de padrões de filtro".
Exemplo: Incluindo branches
Os padrões definidos em branches
são avaliados em relação ao nome da referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento pull_request
para uma solicitação de pull direcionada a:
- Um branch chamado
main
(refs/heads/main
) - Um branch chamado
mona/octocat
(refs/heads/mona/octocat
) - Um branch cujo nome começa com
releases/
, comoreleases/10
(refs/heads/releases/10
)
on:
pull_request:
# Sequence of patterns matched against refs/heads
branches:
- main
- 'mona/octocat'
- 'releases/**'
Exemplo: Excluir branches
Quando um padrão corresponder ao padrão branches-ignore
, o fluxo de trabalho não será executado. Os padrões definidos em branches
são avaliados em relação ao nome da referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento pull_request
, a menos que a solicitação de pull seja direcionada a:
- Um branch chamado
mona/octocat
(refs/heads/mona/octocat
) - Um branch cujo nome corresponde a
releases/**-alpha
, comoreleases/beta/3-alpha
(refs/heads/releases/beta/3-alpha
)
on:
pull_request:
# Sequence of patterns matched against refs/heads
branches-ignore:
- 'mona/octocat'
- 'releases/**-alpha'
Exemplo: Incluindo e excluindo branches
Não é possível usar branches
e branches-ignore
para filtrar o mesmo evento em um só fluxo de trabalho. Caso deseje incluir e excluir padrões de branch para um só evento, use o filtro branches
com o caractere !
para indicar os branches que devem ser excluídos.
Se você definir um branch com o caractere !
, também precisará definir, pelo menos, um branch sem o caractere !
. Caso deseje apenas excluir os branches, use branches-ignore
.
A ordem na qual você define os padrões é importante.
- Um padrão de correspondência negativa (precedido por
!
) após uma correspondência positiva excluirá a referência do Git. - Um padrão positivo correspondente após uma correspondência negativa incluirá a Git ref novamente.
O fluxo de trabalho a seguir será executado em eventos pull_request
para solicitações de pull direcionadas a releases/10
ou releases/beta/mona
, mas não para solicitações de pull direcionadas a releases/10-alpha
ou releases/beta/3-alpha
, porque o padrão !releases/**-alpha
negativo segue o padrão positivo.
on:
pull_request:
branches:
- 'releases/**'
- '!releases/**-alpha'
Using filters to target specific branches or tags for push events
Ao usar o evento push
, você pode configurar um fluxo de trabalho para ser executado em marcas ou em branches específicos.
Use o filtro branches
quando quiser incluir padrões de nomes de branches ou quando quiser incluir e excluir padrões de nomes de branches. Use o filtro branches-ignore
quando quiser excluir apenas padrões de nomes de branches. Não é possível usar os filtros branches
e branches-ignore
para o mesmo evento em um fluxo de trabalho.
Use o filtro tags
quando quiser incluir padrões de nomes de marcas ou quando quiser incluir e excluir padrões de nomes de marcas. Use o filtro tags-ignore
quando quiser excluir apenas padrões de nomes de marcas. Não é possível usar os filtros tags
e tags-ignore
para o mesmo evento em um fluxo de trabalho.
Se você definir apenas tags
/tags-ignore
ou apenas branches
/branches-ignore
, o fluxo de trabalho não será executado para eventos que afetam a referência indefinida do Git. Se você não definir tags
/tags-ignore
nem branches
/branches-ignore
, o fluxo de trabalho será executado para eventos que afetam branches ou marcas. Se você definir branches
/branches-ignore
e paths
, o fluxo de trabalho só será executado quando ambos os filtros forem atendidos.
As palavras-chave branches
, branches-ignore
, tags
e tags-ignore
aceitam padrões glob que usam caracteres como *
, **
, +
, ?
, !
e outros para corresponder a mais de um nome de marca ou de branch. Se um nome contiver um desses caracteres e você quiser ter uma correspondência literal, faça escape de cada um desses caracteres especiais com \
. Para obter mais informações sobre padrões glob, confira a "Folha de referências de padrões de filtro".
Exemplo: Incluindo branches e tags
Os padrões definidos em branches
e tags
são avaliados em relação ao nome de referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento push
para:
- Um branch chamado
main
(refs/heads/main
) - Um branch chamado
mona/octocat
(refs/heads/mona/octocat
) - Um branch cujo nome começa com
releases/
, comoreleases/10
(refs/heads/releases/10
) - Uma marca chamada
v2
(refs/tags/v2
) - Uma marca cujo nome começa com
v1.
, comov1.9.1
(refs/tags/v1.9.1
)
on:
push:
# Sequence of patterns matched against refs/heads
branches:
- main
- 'mona/octocat'
- 'releases/**'
# Sequence of patterns matched against refs/tags
tags:
- v2
- v1.*
Exemplo: Excluindo branches e tags
Quando um padrão corresponder ao padrão branches-ignore
ou tags-ignore
, o fluxo de trabalho não será executado. Os padrões definidos em branches
e tags
são avaliados em relação ao nome de referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento push
, a menos que o evento push
seja para:
- Um branch chamado
mona/octocat
(refs/heads/mona/octocat
) - Um branch cujo nome corresponde a
releases/**-alpha
, comobeta/3-alpha
(refs/releases/beta/3-alpha
) - Uma marca chamada
v2
(refs/tags/v2
) - Uma marca cujo nome começa com
v1.
, comov1.9
(refs/tags/v1.9
)
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.*
Exemplo: Incluindo e excluindo branches e tags
Não é possível usar branches
e branches-ignore
para filtrar o mesmo evento em um fluxo de trabalho individual. Da mesma forma, não é possível usar tags
e tags-ignore
para filtrar o mesmo evento em um fluxo de trabalho individual. Caso deseje incluir e excluir padrões de branch para um evento individual, use o filtro branches
ou tags
com o caractere !
para indicar as marcas ou os branches que devem ser excluídos.
Se você definir um branch com o caractere !
, também precisará definir, pelo menos, um branch sem o caractere !
. Caso deseje apenas excluir os branches, use branches-ignore
. Da mesma forma, se você definir uma marca com o caractere !
, também precisará definir, pelo menos, uma marca sem o caractere !
. Caso deseje apenas excluir as marcas, use tags-ignore
.
A ordem na qual você define os padrões é importante.
- Um padrão de correspondência negativa (precedido por
!
) após uma correspondência positiva excluirá a referência do Git. - Um padrão positivo correspondente após uma correspondência negativa incluirá a Git ref novamente.
O fluxo de trabalho a seguir será executado em pushes para releases/10
ou releases/beta/mona
, mas não em releases/10-alpha
ou releases/beta/3-alpha
porque o padrão !releases/**-alpha
negativo vem após o padrão positivo.
on:
push:
branches:
- 'releases/**'
- '!releases/**-alpha'
Using filters to target specific paths for pull request or push events
Ao usar os eventos push
e pull_request
, você pode configurar um fluxo de trabalho para ser executado com base nos caminhos de arquivo alterados. Os filtros de caminho não são avaliados em pushes de tags.
Use o filtro paths
quando quiser incluir padrões de caminho de arquivo ou quando quiser incluir e excluir padrões de caminho de arquivo. Use o filtro paths-ignore
quando quiser apenas excluir padrões de caminho de arquivo. Não é possível usar os filtros paths
e paths-ignore
para o mesmo evento em um fluxo de trabalho.
Se você definir branches
/branches-ignore
e paths
, o fluxo de trabalho só será executado quando ambos os filtros forem atendidos.
As palavras-chave paths
e paths-ignore
aceitam padrões glob que usam os caracteres curinga *
e **
para fazer a correspondência com mais de um nome de caminho. Para obter mais informações, confira a "Folha de referências de padrões de filtro".
Exemplo: Incluindo caminhos
Se, pelo menos, um caminho corresponder a um padrão no filtro paths
, o fluxo de trabalho será executado. Por exemplo, o fluxo de trabalho a seguir será executado sempre que você efetuar push de um arquivo JavaScript (.js
).
on:
push:
paths:
- '**.js'
Observação: se um fluxo de trabalho for ignorado devido � filtragem de caminho, � filtragem de branch ou a uma mensagem de commit, as verificações associadas a esse fluxo de trabalho permanecerão em um estado "Pendente". Uma solicitação de pull que exige que essas verificações sejam bem-sucedidas não poderá ser mesclada. Para obter mais informações, confira "Como lidar com verificações ignoradas mas obrigatórias".
Exemplo: Excluindo caminhos
Quando todos os nomes de caminho corresponderem aos padrões de paths-ignore
, o fluxo de trabalho não será executado. Se qualquer nome de caminho não corresponder aos padrões de paths-ignore
, mesmo que alguns nomes de caminho correspondam aos padrões, o fluxo de trabalho será executado.
Um fluxo de trabalho com o filtro de caminho a seguir só será executado em eventos push
que incluem, pelo menos, um arquivo fora do diretório docs
na raiz do repositório.
on:
push:
paths-ignore:
- 'docs/**'
Exemplo: Incluindo e excluindo caminhos
Não é possível usar paths
e paths-ignore
para filtrar o mesmo evento em um fluxo de trabalho individual. Caso deseje incluir e excluir padrões de caminho para um evento individual, use o filtro paths
com o caractere !
para indicar os caminhos que devem ser excluídos.
Se você definir um caminho com o caractere !
, também precisará definir, pelo menos, um caminho sem o caractere !
. Caso você deseje apenas excluir os caminhos, use paths-ignore
.
A ordem de definição dos padrões é importante:
- Um padrão de correspondência negativa (precedido por
!
) após uma correspondência positiva excluirá o caminho do Git. - Um padrão positivo correspondente após uma correspondência negativa incluirá o caminho novamente.
Este exemplo é executado sempre que o evento push
inclui um arquivo no diretório sub-project
ou nos respectivos subdiretórios, a menos que o arquivo esteja no diretório sub-project/docs
. Por exemplo, um push que alterar sub-project/index.js
ou sub-project/src/index.js
vai disparar uma execução de fluxo de trabalho, mas um push que só altera sub-project/docs/readme.md
não.
on:
push:
paths:
- 'sub-project/**'
- '!sub-project/docs/**'
Comparações Git diff
Observação: se você efetuar push de mais de mil commits ou se o GitHub não gerar a comparação devido a um tempo limite, o fluxo de trabalho sempre será executado.
O filtro determina se um fluxo de trabalho deve ser executado avaliando os arquivos alterados e executando-os na lista paths-ignore
ou paths
. Se não houver arquivos alterados, o fluxo de trabalho não será executado.
O GitHub gera a lista de arquivos alterados usando diffs de dois pontos para pushes e diffs de três pontos para pull requests:
- Solicitações de pull: as comparações de três pontos são uma comparação entre a versão mais recente do branch do tópico e o commit em que o branch do tópico foi sincronizado pela última vez com o branch base.
- Pushes para branches existentes: uma comparação de dois pontos compara os SHAs principal e base diretamente um com o outro.
- Pushes para novos branches: uma comparação de dois pontos com o pai do ancestral do commit mais profundo enviado por push.
Os diffs limitam-se a 300 arquivos. Se houver arquivos alterados que não correspondam aos primeiros 300 arquivos retornados pelo filtro, o fluxo de trabalho não será executado. Talvez seja necessário criar filtros mais específicos para que o fluxo de trabalho seja executado automaticamente.
Para obter mais informações, confira "Sobre a comparação de branches em solicitações de pull".
Using filters to target specific branches for workflow run events
Ao usar o evento workflow_run
, você pode especificar os branches nos quais o fluxo de trabalho de gatilho precisa ser executado para disparar o fluxo de trabalho.
Os filtros branches
e branches-ignore
aceitam padrões glob que usam caracteres como *
, **
, +
, ?
, !
e outros para corresponder a mais de um nome de branch. Se um nome contiver um desses caracteres e você quiser ter uma correspondência literal, faça escape de cada um desses caracteres especiais com \
. Para obter mais informações sobre padrões glob, confira a "Folha de referências de padrões de filtro".
Por exemplo, um fluxo de trabalho com o seguinte gatilho só será executado quando o fluxo de trabalho chamado Build
for executado em um branch cujo nome começa com releases/
:
on:
workflow_run:
workflows: ["Build"]
types: [requested]
branches:
- 'releases/**'
Um fluxo de trabalho com o seguinte gatilho só será executado quando o fluxo de trabalho chamado Build
for executado em um branch que não seja chamado canary
:
on:
workflow_run:
workflows: ["Build"]
types: [requested]
branches-ignore:
- "canary"
Não é possível usar os filtros branches
e branches-ignore
para o mesmo evento em um fluxo de trabalho. Caso deseje incluir e excluir padrões de branch para um só evento, use o filtro branches
com o caractere !
para indicar os branches que devem ser excluídos.
A ordem na qual você define os padrões é importante.
- Um padrão de correspondência negativa (precedido por
!
) após uma correspondência positiva excluirá o branch. - Um padrão positivo correspondente após uma correspondência negativa incluirá o branch novamente.
Por exemplo, um fluxo de trabalho com o gatilho a seguir será executado quando o fluxo de trabalho chamado Build
for executado em um branch chamado releases/10
ou releases/beta/mona
que não será releases/10-alpha
, releases/beta/3-alpha
ou main
.
on:
workflow_run:
workflows: ["Build"]
types: [requested]
branches:
- 'releases/**'
- '!releases/**-alpha'
Defining inputs for manually triggered workflows
When using the workflow_dispatch
event, you can optionally specify inputs that are passed to the workflow.
The triggered workflow receives the inputs in the github.event.inputs
context. For more information, see "Contexts."
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'
print_tags:
description: 'True to print to STDOUT'
required: true
tags:
description: 'Test scenario tags'
required: true
jobs:
print-tag:
runs-on: ubuntu-latest
if: ${{ github.event.inputs.print_tags == 'true' }}
steps:
- name: Print the input tag to STDOUT
run: echo The tags are ${{ github.event.inputs.tags }}
Using event information
Information about the event that triggered a workflow run is available in the github.event
context. The properties in the github.event
context depend on the type of event that triggered the workflow. For example, a workflow triggered when an issue is labeled would have information about the issue and label.
Viewing all properties of an event
Reference the webhook event documentation for common properties and example payloads. For more information, see "Webhook events and payloads."
You can also print the entire github.event
context to see what properties are available for the event that triggered your workflow:
jobs:
print_context:
runs-on: ubuntu-latest
steps:
- env:
EVENT_CONTEXT: ${{ toJSON(github.event) }}
run: |
echo $EVENT_CONTEXT
Accessing and using event properties
You can use the github.event
context in your workflow. For example, the following workflow runs when a pull request that changes package*.json
, .github/CODEOWNERS
, or .github/workflows/**
is opened. If the pull request author (github.event.pull_request.user.login
) is not octobot
or dependabot[bot]
, then the workflow uses the GitHub CLI to label and comment on the pull request (github.event.pull_request.number
).
on:
pull_request:
types:
- opened
paths:
- '.github/workflows/**'
- '.github/CODEOWNERS'
- 'package*.json'
jobs:
triage:
if: >-
github.event.pull_request.user.login != 'octobot' &&
github.event.pull_request.user.login != 'dependabot[bot]'
runs-on: ubuntu-latest
steps:
- name: "Comment about changes we can't accept"
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
PR: ${{ github.event.pull_request.html_url }}
run: |
gh pr edit $PR --add-label 'invalid'
gh pr comment $PR --body 'It looks like you edited `package*.json`, `.github/CODEOWNERS`, or `.github/workflows/**`. We do not allow contributions to these files. Please review our [contributing guidelines](https://github.com/octo-org/octo-repo/blob/main/CONTRIBUTING.md) for what contributions are accepted.'
For more information about contexts, see "Contexts." For more information about event payloads, see "Webhook events and payloads."
Further controlling how your workflow will run
If you want more granular control than events, event activity types, or event filters provide, you can use conditionals and environments to control whether individual jobs or steps in your workflow will run.
Using conditionals
You can use conditionals to further control whether jobs or steps in your workflow will run.
Example using a value in the event payload
For example, if you want the workflow to run when a specific label is added to an issue, you can trigger on the issues labeled
event activity type and use a conditional to check what label triggered the workflow. The following workflow will run when any label is added to an issue in the workflow's repository, but the run_if_label_matches
job will only execute if the label is named bug
.
on:
issues:
types:
- labeled
jobs:
run_if_label_matches:
if: github.event.label.name == 'bug'
runs-on: ubuntu-latest
steps:
- run: echo 'The label was bug'
Example using event type
For example, if you want to run different jobs or steps depending on what event triggered the workflow, you can use a conditional to check whether a specific event type exists in the event context. The following workflow will run whenever an issue or pull request is closed. If the workflow ran because an issue was closed, the github.event
context will contain a value for issue
but not for pull_request
. Therefore, the if_issue
step will run but the if_pr
step will not run. Conversely, if the workflow ran because a pull request was closed, the if_pr
step will run but the if_issue
step will not run.
on:
issues:
types:
- closed
pull_request:
types:
- closed
jobs:
state_event_type:
runs-on: ubuntu-latest
steps:
- name: if_issue
if: github.event.issue
run: |
echo An issue was closed
- name: if_pr
if: github.event.pull_request
run: |
echo A pull request was closed
For more information about what information is available in the event context, see "Using event information." For more information about how to use conditionals, see "Expressions."
Using environments to manually trigger workflow jobs
If you want to manually trigger a specific job in a workflow, you can use an environment that requires approval from a specific team or user. First, configure an environment with required reviewers. For more information, see "Using environments for deployment." Then, reference the environment name in a job in your workflow using the environment:
key. Any job referencing the environment will not run until at least one reviewer approves the job.
For example, the following workflow will run whenever there is a push to main. The build
job will always run. The publish
job will only run after the build
job successfully completes (due to needs: [build]
) and after all of the rules (including required reviewers) for the environment called production
pass (due to environment: production
).
on:
push:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: build
echo 'building'
publish:
needs: [build]
runs-on: ubuntu-latest
environment: production
steps:
- name: publish
echo 'publishing'
Ambientes, segredos de ambiente e regras de proteção de ambiente estão disponíveis em repositórios públicos para todos os produtos. Para acesso a ambientes, segredos de ambiente e branches de implantação em repositórios privados ou internos, você deve usar GitHub Pro, GitHub Team ou GitHub Enterprise. Para acessar outras regras de proteção de ambiente em repositórios privados ou internos, você deve usar GitHub Enterprise.
Available events
For a full list of available events, see "Events that trigger workflows."