ジョブ実行のトリガー

自動化は次のジョブトリガーをサポートします。

トリガー	説明
`gitPush`	デフォルトで有効になっています。ユーザーが参照 (ブランチ、タグ、コミット、その他の Git 参照) をプロジェクトリポジトリにプッシュした後にジョブを実行します。 `gitPush` の範囲を制限して、プロジェクトリポジトリ内の変更ではなく特定のブランチ、タグ、ディレクトリ、ファイルの変更についてのみがトリガーされるようにすることができます。マルチリポジトリプロジェクトがある場合は、特定のリポジトリ内の変更に対してジョブを実行するように `gitPush` トリガーを設定できます。詳細 \| DSL を参照
`gitBranchDeleted`	特定のブランチがリポジトリから削除された後にジョブを実行します。プロジェクトのデフォルトのブランチ (`main`) でのみ動作します。 DSL を参照
`codeReviewOpened`	プロジェクトでコードレビューまたはマージリクエストが作成された後にジョブを実行します。詳細 \| DSL を参照
`codeReviewClosed`	プロジェクト内のコードレビューまたはマージリクエストが閉じられた後にジョブを実行します。詳細 \| DSL を参照
`schedule`	指定した時刻 (UTC) に定期的にジョブを実行します。プロジェクトのデフォルトのブランチ (`main`) でのみ動作します。 DSL を参照

あるいは、ジョブを実行することもできます。

ジョブページで手動で。詳細
API を使用して POST /api/http/projects/{project}/automation/jobs/{jobId}/start を呼び出します。

ジョブトリガーを設定する

トリガーを設定するには、ジョブの startOn ブロックを使用します。

ジョブに startOn ブロックがない場合は、デフォルトの gitPush トリガーが設定されます。
ジョブに startOn ブロックがある場合、指定されたトリガーのみが設定されます。
空の startOn ブロックがある場合、トリガーは設定されません。

例:

job("Run gradle build on gitpush") {
    // no startOn needed, gitPush is the default
    gradlew("amazoncorretto:17-alpine", "build")
}

job("Run gradle build on gitpush and at 08:00 AM UTC") {
    startOn {
        // here we have to specify gitPush explicitly
        gitPush { enabled = true }
        schedule { cron("0 8 * * *") }
    }

    gradlew("amazoncorretto:17-alpine", "build")
}

特定のリポジトリでジョブトリガーを無効にする

場合によっては、特定のリポジトリの自動ジョブトリガーを無効にする必要がある場合があります。例: デフォルトでは、別のプロジェクトのリポジトリをミラーリングする場合、「git Push」はメインリポジトリだけでなくそのミラーでもオートメーションジョブを実行します。

必要なプロジェクトを開きます。
ジョブページを開き、設定をクリックします。
ジョブトリガーで、必要なリポジトリのトリガーを無効にします。

Git プッシュトリガー

参照、ブランチ、タグ、ファイルパスを追跡する

gitPush フィルターを使用すると、特定の条件でジョブをトリガーできます。

フィルター	説明
`gitPush.anyBranch` , `gitPush.anyBranchMatching`	特定のパターンに一致するブランチまたはブランチをプッシュしてジョブを実行します。詳細
`gitPush.anyTag` , `gitPush.anyTagMatching`	任意のタグ、または特定のパターンに一致するタグをプッシュするときにジョブを実行します。詳細
`gitPush.anyRef` , `gitPush.anyRefMatching`	任意の Git 参照 (英語) (ブランチとタグを含む)、または特定のパターンに一致する参照をプッシュするときにジョブを実行します。詳細
`gitPush.pathFilter`	指定されたディレクトリまたはファイルに変更をプッシュするジョブを実行します。詳細

デフォルトの gitPush 動作

デフォルトでは、gitPush トリガーまたはそのフィルターが設定されていない場合、ジョブはブランチへのプッシュでは実行されますが、タグまたはその他の ref プッシュでは実行されません。次のスクリプトは同等です。

job("Run on gitpush") {
    container("ubuntu")
}

job("Run on gitpush") {
    startOn {
        gitPush()
    }

    container("ubuntu")
}

job("Run on gitpush") {
    startOn {
        gitPush {
            anyBranch()
        }
    }

    container("ubuntu")
}

ブランチでフィルター

デフォルトでは、コミットがリポジトリにプッシュされると、オートメーションは変更がコミットされたのと同じブランチ内の .space.kts ファイルからジョブを実行しようとします。例: cool-feature ブランチに変更をプッシュすると、オートメーションは cool-feature ブランチのこのリビジョンの .space.kts ファイルからジョブを実行しようとします。

anyBranchMatching フィルターを使用すると、オートメーションがスクリプトを実行する必要があるブランチのリストを指定できます。例: 次のジョブは、my-feature ブランチの変更に対してのみ実行されます。

job("Run only in my-feature") {
    startOn {
        gitPush {
            anyBranchMatching {
                +"my-feature"
            }
        }
    }

    // here go job steps...
}

変更が my-feature ブランチにプッシュされた場合、このジョブは my-feature で開始されますが、main やその他のブランチでは開始されません。変更が main ブランチにプッシュされた場合、どのジョブも開始されません。オートメーションは main ブランチでスクリプトを実行しようとしますが、これを防ぐ anyBranchMatching フィルターがあります。

ブランチフィルタリングは次のルールをサポートします。

フィルターは、包含 (+) ルールと除外 (-) ルールをサポートします。
除外ルールは、含めるルールよりも優先されます。
アスタリスク (*) ワイルドカードを使用できます。+"release-*"
除外ルールのみが指定されている場合は、除外されていないすべてのブランチが +"*" に含まれると想定されます。
ブランチへの Git プッシュでジョブをトリガーする場合は、anyBranch を使用します。
例:
job("Run on git push to specific branches") { startOn { gitPush { anyBranchMatching { // add 'main' +"main" // add all branches containing 'feature' +"*feature*" // exclude 'test-feature' -"test-feature" } } } // here go job steps... } job("Run on git push to any branch") { startOn { gitPush { anyBranch() } } // here go job steps... }

タグでフィルター

anyTagMatching を使用すると、特定の Git タグを指定できます。anyTagMatching フィルターは、anyBranchMatching と同じフィルター規則をサポートします。anyTag フィルターは、Git タグを含むコミット時にジョブをトリガーします。

例:

job("Run only with release tags (no beta)") {
    startOn {
        gitPush {
            // run only if there's a release tag
            // e.g., release/v1.0.0
            anyTagMatching {
                +"release/*"
                // but exclude beta releases
                -"release/*-beta"
            }
        }
    }

    // here go job steps...
}

job("Run on git push with any tag") {
    startOn {
        gitPush {
            anyTag()
        }
    }

    // here go job steps...
}

参照によるフィルタリング

ブランチやタグによるフィルタリングが不十分な場合、refs によるフィルタリングが微調整に必要になります。anyRefMatching を使用すると、ブランチ、タグ、特定のコミットへの参照など、任意の Git 参照を指定できます。次のフィルターは基本的に同じです。

gitPush {
    anyBranchMatching {
        +"main"
    }
}

gitPush {
    anyRefMatching {
        +"refs/heads/main"
    }
}

anyRefMatching フィルターは、anyBranchMatching または anyTagMatching と同じフィルタリングルールをサポートしますが、さらに次のことをサポートします。

フィルターは、Kotlin 正規表現 (Regex) をサポートします。+Regex("""refs/heads/release-\d+\.\d+""") 正規表現ルールは、refs/.../ プレフィックスを含む完全な参照名に適用されます。
フィルターは、refs/merge などの Space 固有の参照タイプを含むすべての参照タイプをサポートします。例: +"refs/merge/*/head" を使用すると、マージリクエストに更新があるたびにジョブを実行できます。
例:
job("Run on git push on specific refs") { startOn { gitPush { anyRefMatching { +"refs/heads/release-*" +"refs/tags/v2.*" +Regex("""refs/heads/dev-v\d+\.\d+\.\d+""") } } } // here go job steps... } job("Run on git push on any ref") { startOn { gitPush { // all refs, including branches, tags, and merge requests anyRef() } } // here go job steps... }

パスによるフィルター

pathFilter を使用すると、特定のディレクトリおよびファイルへのパスを指定できます。例: 以下のジョブは、Main.kt ファイルに変更があった場合にのみ実行されます。

job("Run on change in Main.kt") {
    startOn {
        gitPush {
            pathFilter {
                +"Main.kt"
            }
        }
    }

    // here go job steps...
}

pathFilter を使用して anyBranchMatching、anyTagMatching、または anyRefMatching を微調整できます。オートメーションはまず、特定のブランチに変更があるかどうか、特定のタグが適用されているかどうかを確認し、その後で pathFilter を適用します。他のフィルターが指定されていない場合、pathFilter は現在のブランチ (変更がコミットされたもの) 内でのみ機能します。

pathFilter は次のフィルタリングルールをサポートしています。

少なくとも 1 つのファイルが指定されたフィルターに一致する場合、ジョブは実行されます。
フィルターは、包含 (+) ルールと除外 (-) ルールをサポートします。
単一の + パスルールが指定されている場合、他のすべてのパスは除外されます。逆に、単一の - パスルールが指定されている場合は、他のすべてのパスが含まれます。
作業ディレクトリからの相対パスを指定する必要があります。
現在のディレクトリ内のみでファイルを照合するにはアスタリスク (*) ワイルドカードを使用し、再帰的照合には二重アスタリスク (**) を使用できます。例: src/tests/* は、tests ディレクトリ内のすべてのファイルと一致します。src/tests/** は、tests 内のすべてのファイルとそのすべてのサブディレクトリに一致します。
より具体的なパスは、それほど具体的ではないパスよりも優先されます。+"src/tests/MyTests.kt" は -"src/tests/**" よりも優先されます。
例:
job("Run on git push") { startOn { gitPush { // run only on changes in 'main' anyBranchMatching { +"refs/heads/main" } pathFilter { // include all from 'targets' dir +"targets/**" // exclude 'targets/main' dir -"targets/main/**" // include all 'Main.kt' files in the project // As this rule is more specific, // 'Main.kt' will be included even if // it's located in 'targets/main' +"**/Main.kt" // include all '.java' files from the 'common' dir +"common/**/*.java" } } } // here go job steps... }
次の場合、自動化は pathFilter を無視してジョブを実行します。
- プッシュには 250 を超えるコミットが含まれており
- 10000 を超えるファイルが変更されました。
- プッシュには、1000 を超える変更されたファイルを含むコミットが含まれています。

gitPush フィルターを結合する

gitPush フィルターは組み合わせ可能です。結果のフィルターはルール (anyBranch[Matching] OR anyTag[Matching] OR anyRef[Matching]) AND pathFilter に従います。

anyBranch[Matching]、anyTag[Matching]、anyRef[Matching] フィルターは OR ルールと結合されます。指定されたフィルターのいずれかが一致する場合にジョブが実行されます。
pathFilter は AND ルールと結合されます。ジョブは、指定されたブランチ /tag/ref フィルターのいずれかが一致する場合に実行されますが、指定されたパスで変更が行われた場合にのみ実行されます。

例:

job("Run gradle build on gitpush") {
    startOn {
        gitPush {
            // run a job on pushing any branch
            anyBranch()
            // OR a tag matching v*
            anyTagMatching {
                +"v*"
            }

            // AND only if the change is in the main directory
            pathFilter {
                +"main/**"
            }
        }
    }

    gradlew("amazoncorretto:17-alpine", "build")
}

他のプロジェクトリポジトリの変更を追跡する

場合によっては、複数のプロジェクトリポジトリのソースコードを使用する複雑なビルドを構成する必要がある場合があります。例: すべてのビルドスクリプトを含む別のリポジトリを作成し、他のリポジトリには .space.kts ファイルがまったく含まれないようにすることもできます。

gitPush トリガーの repository プロパティを使用すると、job が変更を追跡するリポジトリを指定できます。例: first-repository と second-repository という 2 つのリポジトリを持つプロジェクトがあります。.space.kts スクリプトは first-repository にあり、オートメーションで second-repository の変更時にスクリプトをトリガーしたいとします。

job("Run on change in second-repository") {
    startOn {
        gitPush {
            repository = "second-repository"
        }

        // if you also want to run the job
        // on changes in the current repo (first-repository)
        // add the following line
        gitPush {}
    }

    // check out the content of second-repo
    // as this won't happen automatically
    git("second-repository")

    // here go job steps...
}

しかし、second-repository のブランチにコミットがプッシュされた場合、.space.kts スクリプトは first-repository のどのブランチで実行されるのでしょうか ? この場合、オートメーションはブランチとの一致を試みます。オートメーションは、コミットがプッシュされたものと同じ名前を持つブランチを first-repository で検索します。例: second-repository は my-feature ブランチへのコミットを取得します。first-repository に .space.kts スクリプトを含む my-feature ブランチがある場合、このスクリプトが開始されます。

同様に、second-repository が main ブランチへのコミットを取得すると、first-repository/main ブランチからのスクリプトが開始されます。

second-repository が first-repository に存在しない新しいブランチを取得した場合、オートメーションは first-repository/main ブランチからスクリプトの実行を試行します。main ブランチは、ある種のフォールバックブランチとして機能します。

main ブランチをフォールバックブランチとして機能させたくない場合、またはオートメーションで特定のブランチでのみスクリプトを実行するようにしたい場合は、 anyBranchMatching フィルター (または特定のパスによる変更を追跡するための pathFilter ) を追加できます。例: main リポジトリへのコミットでのみジョブを実行するには:

job("Run on change in second-repository / main branch") {
    startOn {
        gitPush {
            repository = "second-repository"
            anyBranchMatching {
                +"main"
            }
        }
    }

    git("second-repository")

    // here go job steps...
}

コミットが second-repository/my-feature ブランチにプッシュされたが、first-repository/my-feature ブランチに .space.kts スクリプトがない (またはスクリプトに repository="second-repository" トリガーがない) 場合はどうなりますか ? この場合、実行するものが何もないため、オートメーションはジョブの実行をトリガーしません。

ジョブページでマルチリポジトリビルドを表示する

他のリポジトリを参照するジョブは相互参照されたジョブと呼ばれます。相互参照されたジョブを含むリポジトリのジョブページを開くと、相互参照されたジョブと「通常の」ジョブの違いはわかりません。

ただし、ジョブを他のリポジトリからジョブによって参照されたリポジトリに切り替えると、相互参照されたジョブのリストが表示されます。

ジョブの実行をスキップする

コミットメッセージに次の文字列 (大文字と小文字は区別されません) のいずれかが含まれている場合、有効な gitPush トリガーを持つジョブは実行されません。

[ci skip]
[skip ci]

こうすることで、特定のコミットのジョブの実行をスキップできます。例:

git commit -m "My commit message [ci skip]"

複数のコミットを含む git プッシュのジョブ実行をスキップする場合は、各コミットメッセージに [ci skip] または [skip ci] 文字列が含まれている必要があります。

コードレビューとマージリクエストのトリガー

codeReviewOpened および codeReviewClosed を使用すると、プロジェクト内でコードレビューまたはマージリクエストが開かれたとき、または閉じられたときにジョブを実行できます。例: これは、ジョブの結果をマージリクエストの要件として使用する場合に便利です。

branchToCheckout パラメーターを使用すると、ジョブがチェックアウトするブランチを指定できます。branchToCheckout パラメーターには次の値を指定できます。

branchToCheckout = CodeReviewBranch.MERGE_REQUEST_SOURCE – このコードレビューがマージリクエストの場合はソースブランチをチェックアウトし、一連のコミットのコードレビューの場合はリポジトリのデフォルトのブランチ (通常は main) をチェックアウトします。
branchToCheckout = CodeReviewBranch.MERGE_REQUEST_TARGET – このコードレビューがマージリクエストの場合はターゲットブランチをチェックアウトし、一連のコミットのコードレビューの場合はリポジトリのデフォルトのブランチ (通常は main) をチェックアウトします。
branchToCheckout が指定されていないか、branchToCheckout = CodeReviewBranch.REPOSITORY_DEFAULT の場合、ジョブはデフォルトのリポジトリブランチ (通常は main) をチェックアウトします。

例:

job("Run gradle build") {
    // the job will check out source branch if it's a merge request
    // or 'main' if it's a code review for a set of commits
    startOn {
        codeReviewOpened {
            branchToCheckout = CodeReviewBranch.MERGE_REQUEST_SOURCE
        }
    }

    gradlew("amazoncorretto:17-alpine", "build")
}

マージリクエストの変更に対してジョブを実行する場合は、gitPush トリガーを使用します。

job("Run on any update to merge request") {
    startOn {
        gitPush {
            // Space stores references to merge requests in the refs/merge/
            anyRefMatching {
                +"refs/merge/*/head"
            }
        }
    }

    // here go job steps...
}

最終更新日: 2024 年 2 月 02 日

JetBrains Space ヘルプ