ノート: GitHubホストランナーは、現在GitHub Enterprise Serverでサポートされていません。 GitHubパブリックロードマップで、計画されている将来のサポートに関する詳しい情� �を見ることができます。
About workflow triggers
Workflow triggers are events that cause a workflow to run. These events can be:
- Events that occur in your workflow's repository
- Events that occur outside of GitHub Enterprise Server and trigger a
repository_dispatch
event on GitHub Enterprise Server - Scheduled times
- Manual
For example, you can configure your workflow to run when a push is made to the default branch of your repository, when a release is created, or when an issue is opened.
Workflow triggers are defined with the on
key. 詳しい情� �については、「GitHub Actions のワークフロー構文」を参照してく� さい。
ワークフローの実行がトリガーされるには、以下のステップが生じます。
-
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. ワークフローを実行すると、GitHub Enterprise Server はランナー環境において
GITHUB_SHA
(コミット SHA) およびGITHUB_REF
(Git ref) 環境変数を設定します。 詳しい情� �については、「環境変数の利用」を参照してく� さい。
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. これによって、予想外の再帰的なワークフローの実行が生じないようになります。 たとえば、ワークフローの実行によってリポジトリのGITHUB_TOKEN
を使ったコードのプッシュが行われた� �合、そのリポジトリにpush
イベントが生じた際に実行されるよう設定されたワークフローが含まれていても、新しいワークフローの実行は行われません。 詳しい情� �については「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. 個人アクセストークンを作成し、それをシークレットとして保存する必要があります。 GitHub Actionsの利用コストを最小化するために、再帰的あるいは意図しないワークフローの実行が生じないようにしてく� さい。 個人アクセストークンの作成に関する詳しい情� �については「個人アクセストークンの作成」を参照してく� さい。 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
For example, a workflow with the following on
value will run when a push is made to any branch in the workflow's repository:
on: push
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:
on: [push, fork]
If you specify multiple events, only one of those events needs to occur to trigger your workflow. If multiple triggering events for your workflow occur at the same time, multiple workflow runs will be triggered.
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. If you specify activity types or filters for an event and your workflow triggers on multiple events, you must configure each event separately. 設定を持たないイベントも含め、すべてのイベントにはコロン (:
)を追� しなければなりません。
For example, a workflow with the following on
value will run when:
- A label is created
- A push is made to the
main
branch in the repository - A push is made to a GitHub Pages-enabled branch
on:
label:
types:
- created
push:
branches:
- main
page_build:
Using event activity types
Some events have activity types that give you more control over when your workflow should run. Use on.<event_name>.types
to define the type of event activity that will trigger a workflow run.
For example, the issue_comment
event has the created
, edited
, and deleted
activity types. If your workflow triggers on the label
event, it will run whenever a label is created, edited, or deleted. If you specify the created
activity type for the label
event, your workflow will run when a label is created but not when a label is edited or deleted.
on:
label:
types:
- created
If you specify multiple activity types, only one of those event activity types needs to occur to trigger your workflow. If multiple triggering event activity types for your workflow occur at the same time, multiple workflow runs will be triggered. For example, the following workflow triggers when an issue is opened or labeled. If an issue with two labels is opened, three workflow runs will start: one for the issue opened event and two for the two issue labeled events.
on:
issue:
types:
- opened
- labeled
各イベントとそのアクティビティタイプの詳細については、「ワークフローをトリガーするイベント」を参照してく� さい。
Using filters
Some events have filters that give you more control over when your workflow should run.
For example, the push
event has a branches
filter that causes your workflow to run only when a push to a branch that matches the branches
filter occurs, instead of when any push occurs.
on:
push:
branches:
- main
- 'releases/**'
Using filters to target specific branches for pull request events
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
, 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."
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/
, likereleases/10
(refs/heads/releases/10
)
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
, likebeta/3-alpha
(refs/releases/beta/3-alpha
)
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.
パターンを定義する� �序により、結果に違いが生じます。
- 肯定のマッチングパターンの後に否定のマッチングパターン ("
!
" のプレフィクス) を定義すると、Git ref を除外します。 - 否定のマッチングパターンの後に肯定のマッチングパターンを定義すると、Git ref を再び含めます。
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.
on:
pull_request:
branches:
- 'releases/**'
- '!releases/**-alpha'
Using filters to target specific branches or tags for push events
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
, 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."
Example: Including branches and tags
branches
およびtags
で定義されているパターンは、Git refの名前と照らし合わせて評価されます。 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/
, likereleases/10
(refs/heads/releases/10
) - A tag named
v2
(refs/tags/v2
) - A tag whose name starts with
v1.
, likev1.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.*
Example: Excluding branches and tags
When a pattern matches the branches-ignore
or tags-ignore
pattern, the workflow will not run. branches
およびtags
で定義されているパターンは、Git refの名前と照らし合わせて評価されます。 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
, likebeta/3-alpha
(refs/releases/beta/3-alpha
) - A tag named
v2
(refs/tags/v2
) - A tag whose name starts with
v1.
, likev1.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.*
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.
パターンを定義する� �序により、結果に違いが生じます。
- 肯定のマッチングパターンの後に否定のマッチングパターン ("
!
" のプレフィクス) を定義すると、Git ref を除外します。 - 否定のマッチングパターンの後に肯定のマッチングパターンを定義すると、Git ref を再び含めます。
以下のワークフローは、releases/10
や releases/beta/mona
へのプッシュで実行されますが、releases/10-alpha
や releases/beta/3-alpha
へのプッシュでは実行されません。肯定のマッチングパターンの後に、否定のマッチングパターン !releases/**-alpha
が続いているからです。
on:
push:
branches:
- 'releases/**'
- '!releases/**-alpha'
Using filters to target specific paths for pull request or push events
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. 詳しい情� �については、「フィルタパターンのチートシート」を参照してく� さい。
Example: Including paths
paths
フィルタのパターンにマッチするパスが1つでもあれば、ワークフローは実行されます。 For example, the following workflow would run anytime you push a JavaScript file (.js
).
on:
push:
paths:
- '**.js'
Example: Excluding paths
すべてのパス名が paths-ignore
のパターンと一致する� �合、ワークフローは実行されません。 If any path names do not match patterns in paths-ignore
, even if some path names match the patterns, the workflow will run.
以下のパスフィルタを持つワークフローは、リポジトリのルートにある docs
ディレクトリ外のファイルを少なくとも1つ含むpush
イベントでのみ実行されます。
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.
パターンを定義する� �序により、結果に違いが生じます:
- 肯定のマッチの後に否定のマッチングパターン(
!
がプレフィックスされている)を置くと、パスが除外されます。 - 否定のマッチングパターンの後に肯定のマッチングパターンを定義すると、パスを再び含めます。
この例は、push
イベントにsub-project
ディレクトリあるいはそのサブディレクトリ内のファイルが含まれ、そのファイルがsub-project/docs
ディレクトリ内にあるのでない� �合に実行されます。 たとえばsub-project/index.js
もしくはsub-project/src/index.js
を変更するプッシュはワークフローを実行させますが、sub-project/docs/readme.md
� けを変更するプッシュは実行させません。
on:
push:
paths:
- 'sub-project/**'
- '!sub-project/docs/**'
Git diffの比較
Note: If you push more than 1,000 commits, or if GitHub does not generate the diff due to a timeout, the workflow will always run.
フィルタは、変更されたファイルをpaths-ignore
あるいはpaths
リストに対して評価することによって、ワークフローを実行すべきか判断します。 ファイルが変更されていない� �合、ワークフローは実行されません。
GitHubはプッシュに対してはツードットdiff、プルリクエストに対してはスリードットdiffを使って変更されたファイルのリストを生成します。
- プルリクエスト: スリードットdiffは、トピックブランチの最新バージョンとトピックブランチがベースブランチと最後に同期されたコミットとの比較です。
- 既存のブランチへのプッシュ: ツードットdiffは、headとベースのSHAを互いに直接比較します。
- 新しいブランチへのプッシュ: 最も深いプッシュの先祖の親に対するツードットdiffです。
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.
詳しい情� �については「プルリクエスト中のブランチの比較について」を参照してく� さい。
Using filters to target specific branches for workflow run events
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."
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/
:
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
:
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.
パターンを定義する� �序により、結果に違いが生じます。
- 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
.
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. 詳細については、「コンテキスト」を参照してく� さい。
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'
tags:
description: 'Test scenario tags'
required: false
jobs:
print-tag:
runs-on: ubuntu-latest
steps:
- name: Print the input tag to STDOUT
run: echo The tag is ${{ github.event.inputs.tag }}
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 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. 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'
For more information, see "Expressions."
Available events
For a full list of available events, see "Events that trigger workflows."