翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# トリガーとフィルタリングを使用してパイプラインを自動的に開始する
トリガーを使用すると、特定のブランチやプルリクエストの変更を検出したときなど、特定のイベントタイプやフィルタリングされたイベントタイプに応じて開始するようにパイプラインを設定できます。トリガーは、GitHub、Bitbucket、GitLab など、CodePipeline の `CodeStarSourceConnection` アクションを実行する接続を使用するソースアクションに対して設定できます。接続を使用するソースアクションの詳細については、「[CodeConnections を使用してサードパーティのソースプロバイダーを追加する](pipelines-connections.md)」を参照してください。
CodeCommit や S3 などのソースアクションは、自動変更検出を使用して、変更があったときにパイプラインを開始します。詳細については、「[CodeCommit ソースアクションと EventBridge](triggering.md)」を参照してください。
トリガーは、コンソールまたは CLI を使用して指定します。
フィルタータイプは、以下のように指定します。
+ **フィルターなし**
このトリガー設定は、アクション設定の一環として指定したデフォルトブランチへのあらゆるプッシュに応じてパイプラインを開始します。
+ **フィルターを指定**
コードプッシュのブランチ名などの特定のフィルターでパイプラインを開始し、正確なコミットを取得するフィルターを追加します。これにより、変更があっても自動的に開始しないようにパイプラインを設定することもできます。
+ **プッシュ**
+ 有効なフィルターの組み合わせは以下のとおりです。
+ **Git タグ**
包含または除外
+ **ブランチ**
包含または除外
+ **ブランチ \+ ファイルパス**
包含または除外
+ **プルリクエスト**
+ 有効なフィルターの組み合わせは以下のとおりです。
+ **ブランチ**
包含または除外
+ **ブランチ \+ ファイルパス**
包含または除外
+ **変更を検出しない**
トリガーを追加せず、変更があってもパイプラインを自動的に開始しません。
次の表は、イベントタイプ別の有効なフィルターオプションを示しています。また、アクション設定の自動変更検出がデフォルトで true または false となるトリガー設定も示しています。
****
| トリガーの設定 | イベントタイプ | フィルターのオプション | 変更を検出する |
| --- | --- | --- | --- |
| トリガーを追加 – フィルターなし | なし | なし | true |
| トリガーを追加 – コードプッシュ時にフィルタリング | プッシュイベント | Git タグ、ブランチ、ファイルパス | false |
| トリガーを追加 – プルリクエストのフィルタリング | プルリクエスト | ブランチ、ファイルパス | false |
| トリガーなし - 検出しない | なし | なし | false |
**注記**
このトリガータイプは自動変更検出を (`Webhook` トリガータイプとして) 使用します。このトリガータイプを使用するソースアクションプロバイダーは、コードプッシュ用に設定された接続 (Bitbucket Cloud、GitHub、GitHub Enterprise Server、GitLab.com、GitLab セルフマネージド) です。
フィールド定義とトリガーのその他のリファレンスについては、を参照してください。
JSON 構造内のフィールド定義のリストについては、「[`triggers`](pipeline-requirements.md#pipeline.triggers)」を参照してください。
フィルタリングでは、「[構文での glob パターンの使用](syntax-glob.md)」で詳述しているように、正規表現パターンを glob 形式でサポートしています。
**注記**
ファイルパスでトリガーをフィルタリングするパイプラインの場合、ファイルパスフィルターを含むブランチの最初の作成時にパイプラインが開始しないことがあります。詳細については、「[ファイルパスによるトリガーフィルタリングを使用する接続を持つパイプラインは、ブランチの作成時に開始しない可能性があります](troubleshooting.md#troubleshooting-file-paths-filtering)」を参照してください。
## トリガーフィルターに関する考慮事項
トリガーを使用するときは、以下の考慮事項が適用されます。
+ ソースアクションごとに複数のトリガーを追加することはできません。
+ トリガーには複数のフィルタータイプを追加できます。例については、[4: 競合する包含と除外の 2 つのプッシュフィルタータイプを持つトリガー](#example-filter-multiple-push)を参照してください。
+ ブランチフィルターとファイルパスフィルターを含むトリガーの場合、ブランチを初めてプッシュすると、新しく作成したブランチでは変更されたファイルのリストにアクセスできないため、パイプラインは実行されません。
+ プルリクエストをマージすると、プッシュ (ブランチフィルター) とプルリクエスト (ブランチフィルター) のトリガー設定が交差して、2 つのパイプライン実行がトリガーされる場合があります。
+ プルリクエストイベントでパイプラインをトリガーするフィルターの場合、クローズドプルリクエストイベントタイプでは、接続用のサードパーティーリポジトリプロバイダーがマージイベントに対して別のステータスを持つ場合があります。例えば、Bitbucket では、マージの Git イベントはプルリクエストクローズイベントではありません。ただし、GitHub では、プルリクエストのマージはクローズイベントです。詳細については、「[プロバイダーによるトリガーのプルリクエストイベント](#pipelines-filter-pullrequest-events)」を参照してください。
+ パイプライン内の複数のソースアクションが接続を介して同じリポジトリの異なるブランチを参照する場合、パイプラインを確実にトリガーするブランチは 1 つだけです。接続のウェブフックサブスクリプションは、ブランチごとではなく、パイプラインとリポジトリの組み合わせに登録されます。回避策として、ブランチごとに個別のパイプラインを使用します。
## プロバイダーによるトリガーのプルリクエストイベント
次の表は、プルリクエストのクローズなど、プロバイダーによるプルリクエストイベントタイプにつながる Git イベントの概要を示しています。
****
| | 接続のリポジトリプロバイダー | トリガーの PR イベント | Bitbucket | GitHub | GHES | GitLab |
| --- | --- | --- | --- | --- | --- | --- |
| 開始 - このオプションは、ブランチ/ファイルパスのプルリクエストが作成されると、パイプラインをトリガーします。 | プルリクエストを作成すると、開始済み Git イベントが発生します。 | プルリクエストを作成すると、開始済み Git イベントが発生します。 | プルリクエストを作成すると、開始済み Git イベントが発生します。 | プルリクエストを作成すると、開始済み Git イベントが発生します。 |
| 更新 - このオプションは、ブランチ/ファイルパスのプルリクエストのリビジョンが公開されると、パイプラインをトリガーします。 | 更新を発行すると、更新済み Git イベントが発生します。 | 更新を発行すると、更新済み Git イベントが発生します。 | 更新を発行すると、更新済み Git イベントが発生します。 | 更新を発行すると、更新済み Git イベントが発生します。 |
| 終了済み - このオプションは、ブランチ/ファイルパスのプルリクエストが終了したときにパイプラインをトリガーします。 | Bitbucket でプルリクエストをマージすると、終了済み Git イベントが発生します。重要: マージせずに Bitbucket でプルリクエストを手動で閉じても、終了済み Git イベントは発生しません。 | プルリクエストをマージするか手動で閉じると、終了済み Git イベントが発生します。 | プルリクエストをマージするか手動で閉じると、終了済み Git イベントが発生します。 | プルリクエストをマージするか手動で閉じると、終了済み Git イベントが発生します。 |
## トリガーフィルターの例
プッシュとプルリクエストのイベントタイプのフィルターを含む Git 設定では、指定した複数のフィルターが互いに競合する場合があります。プッシュおよびプルリクエストのイベントの有効なフィルターの組み合わせの例を次に示します。トリガーには、トリガー設定に 2 つのプッシュフィルタータイプなど、複数のフィルタータイプを含めることができます。プッシュリクエストフィルタータイプとプルリクエストフィルタータイプは、それらの間で OR 演算を使用します。つまり、一致するとパイプラインが開始されます。同様に、各フィルタータイプには、filePaths や branches などの複数のフィルターを含めることができます。これらのフィルターは AND 演算を使用します。つまり、完全一致のみがパイプラインを開始します。各フィルタータイプには、包含と除外を含めることができます。除外は包含よりも優先されます。ブランチまたはファイルパスが除外パターンと一致する場合、インクルードパターンとも一致しても、パイプラインはトリガーされません。コミットが複数のファイルを変更すると、各ファイルはフィルタに対して個別に評価されます。変更されたファイルが合格した場合 (インクルードに一致し、インクルードと一致しない場合）、パイプラインが開始されます。ブランチ名など、包含/除外内の名前は、OR 演算を使用します。次のリストは、Git 設定オブジェクトの各部分の演算をまとめたものです。
JSON 構造内のフィールド定義のリストと、包含と除外の詳細なリファレンスについては、「[`triggers`](pipeline-requirements.md#pipeline.triggers)」を参照してください。
**Example 1: ブランチとファイルパスのフィルターを含むフィルタータイプ (AND 演算)**
プルリクエストなど単一フィルタータイプの場合、複数のフィルターを組み合わせることができます。これらのフィルターは AND 演算を使用するため、完全に一致する場合にのみパイプラインが開始します。次の例は、2 つの異なるフィルター (`filePaths` と `branches`) を持つプッシュイベントタイプの Git 設定を示しています。次の例で、`filePaths` は `branches` と AND 演算されます。
```
{
"filePaths": {
"includes": ["common/**/*.js"]
},
"branches": {
"includes": ["feature/**"]
}
}
```
上の Git 設定の場合、次の例は AND 演算の成功により、パイプライン実行を開始するイベントを示しています。つまり、ファイルパス `common/app.js` はフィルターに含まれ、指定されたブランチ `refs/heads/feature/triggers ` に影響がない場合でも、パイプラインは AND として開始されます。
```
{
"ref": "refs/heads/feature/triggers",
...
"commits": [
{
...
"modified": [
"common/app.js"
]
...
}
]
}
```
次の例は、ブランチはフィルタリングできるが、ファイルパスはフィルタリングできないため、パイプライン実行を開始しない、上記設定を持つトリガーのイベントを示しています。
```
{
"ref": "refs/heads/feature/triggers",
...
"commits": [
{
...
"modified": [
"src/Main.java"
]
...
}
]
}
```
**Example 2: 包含よりも優先される除外**
1 つのフィルター内では、 除外が include よりも優先されます。次の例は、設定オブジェクト内に 1 つのフィルター (`branches`) を含む Git 設定を示しています。つまり、ブランチが除外パターン (`feature-branch`例では ) に一致する場合、インクルードパターンとも一致してもパイプラインはトリガーされません。`main` ブランチなど、包含パターンが一致し、除外パターンが一致しない場合、パイプラインがトリガーされます。
たとえば、次の JSON の例の場合:
+ コミットを `main` ブランチにプッシュすると、パイプラインがトリガーされます。
+ コミットを `feature-branch` ブランチにプッシュすると、パイプラインはトリガーされません。
```
{
"branches": {
"Includes": [
"main"
],
"Excludes": [
"feature-branch"
]
}
```
**Example 3: プッシュおよびプルリクエストフィルタータイプ (OR オペレーション）、ファイルパスとブランチのフィルター (AND オペレーション）、および包含/除外 (除外が優先) を持つトリガー**
プッシュイベントタイプとプルリクエストイベントタイプを含むトリガーなどのトリガー設定オブジェクトは、2 つのイベントタイプ間で OR 演算を使用します。次の例は、`main` ブランチを含むプッシュイベントタイプと、同じブランチ `main` を除外する 1 つのプルリクエストイベントタイプのトリガー設定を示しています。さらに、プッシュイベントタイプには、1 つのファイルパス `LICENSE.txt` が除外され、1 つのファイルパス `README.MD` が含まれます。2 番目のイベントタイプでは、`feature-branch`ブランチ (含まれる) `Created` で `Closed`または のいずれかのプルリクエストがパイプラインを開始し、 `feature-branch-2` または `main`ブランチ (含まれない) でプルリクエストを作成または閉じるときにパイプラインが開始しません。各イベントタイプ内では、 除外が include よりも優先されます。たとえば、`feature-branch`ブランチのプルリクエストイベント (プルリクエストに含まれる) の場合、プッシュイベントタイプは`feature-branch`ブランチを除外するため、プッシュはパイプラインをトリガーしません。
次の例では
+ `README.MD` ファイルパス (包含) の `main` ブランチ (包含) にコミットをプッシュすると、パイプラインがトリガーされます。
+ `feature-branch` ブランチ (除外) でコミットをプッシュすると、パイプラインはトリガーされません。
+ 包含ブランチで、`README.MD` ファイルパス (包含) を編集すると、パイプラインがトリガーされます。
+ 含まれているブランチでは、`LICENSE.TXT`ファイルパス (除外) のみを編集してもパイプラインはトリガーされません。ただし、同じコミットも変更 `README.MD` (含まれている) された場合、各ファイルは個別に評価されるため、パイプラインがトリガーされます。
+ `feature-branch` ブランチでプルリクエストを閉じると、プルリクエストイベントタイプと CLOSED イベントタイプに `feature-branch` が含まれているため、パイプラインがトリガーされます。
次の画像は、構成を示しています。
以下は、設定の JSON の例です。
```
"triggers": [
{
"providerType": "CodeStarSourceConnection",
"gitConfiguration": {
"sourceActionName": "Source",
"push": [
{
"branches": {
"includes": [
"main"
],
"excludes": [
"feature-branch",
"feature-branch-2"
]
},
"filePaths": {
"includes": [
"README.md"
],
"excludes": [
"LICENSE.txt"
]
}
}
],
"pullRequest": [
{
"events": [
"CLOSED",
"OPEN"
],
"branches": {
"includes": [
"feature-branch"
],
"excludes": [
"feature-branch-2",
"main"
]
}
}
]
}
}
]
},
```
**Example 4: 競合する包含と除外の 2 つのプッシュフィルタータイプを持つトリガー**
次の図は、タグ `release-1` (包含) でフィルタリングするように指定するプッシュフィルタータイプを示しています。2 番目のプッシュフィルタータイプが追加され、ブランチ `main` をフィルタリングするように指定され(包含)、`feature*` ブランチへのプッシュを開始しないように指定されます (除外)。
次の例では
+ `feature-branch` ブランチのタグ `release-1` (最初のプッシュフィルターに含まれる) (2 番目のプッシュフィルター`feature*`の を除く) からリリースをプッシュすると、2 つのプッシュフィルタータイプがそれらの間で OR オペレーションを使用し、最初のプッシュフィルター (タグ`release-1`) が一致するため、パイプラインがトリガーされます。
+ `main` ブランチ (2 番目のプッシュフィルターに含まれる) からリリースをプッシュすると、パイプラインは開始されます。
次の [編集] ページの例は、2 つのプッシュフィルタータイプと、それらのフィルタータイプの包含と除外の設定を示しています。
以下は、設定の JSON の例です。
```
"triggers": [
{
"providerType": "CodeStarSourceConnection",
"gitConfiguration": {
"sourceActionName": "Source",
"push": [
{
"tags": {
"includes": [
"release-1"
]
}
},
{
"branches": {
"includes": [
"main*"
],
"excludes": [
"feature*"
]
}
}
]
}
}
]
},
```
**Example 5: デフォルトのアクション設定 BranchName が手動起動に使用される間に設定されたトリガー**
アクション設定のデフォルト `BranchName` フィールドは、パイプラインを手動で開始するときに使用する単一のブランチを定義しますが、フィルター付きのトリガーは、指定した任意のブランチに使用できます。
以下は、`BranchName` フィールドを示すアクション設定の JSON の例です。
```
{
"name": "Source",
"actions": [
{
"name": "Source",
"actionTypeId": {
"category": "Source",
"owner": "AWS",
"provider": "CodeStarSourceConnection",
"version": "1"
},
"runOrder": 1,
"configuration": {
"BranchName": "main",
"ConnectionArn": "ARN",
"DetectChanges": "false",
"FullRepositoryId": "{{owner-name}}/my-bitbucket-repo",
"OutputArtifactFormat": "CODE_ZIP"
},
"outputArtifacts": [
{
"name": "SourceArtifact"
}
],
"inputArtifacts": [],
"region": "us-west-2",
"namespace": "SourceVariables"
}
],
```
次のアクション出力の例は、パイプラインを手動で開始したときに使用されたデフォルトのブランチ main を示しています。
次のアクション出力の例は、プルリクエストでフィルタリングされたときにトリガーに使用されたプルリクエストとブランチを示しています。
