web-dev-qa-db-ja.com

JenkinsワークフロープラグインでSCMポーリングを機能させる方法

通常のフリースタイルプロジェクトでは、リリースしたいGitリポジトリを指すようにSCMプラグインを構成し、「ポーリングSCM」オプションを有効にします。これにより、Stash Webhookを構成して、変更があったときにJenkinsに通知するそのレポに。このようにして、変更がレポにプッシュされるたびにジョブをトリガーできます。

しかし、フリースタイルプロジェクトの代わりにワークフローを使用する場合、ビルドする必要のあるコードのSCMは、groovyワークフロースクリプトでプログラムによって指定されます。つまり、Stash Webhookをリッスンしていません。代わりに、ワークフローで直接構成されているSCMは、groovyスクリプト自体のSCMです。これは、ビルド/リリースしようとしているコードベースとは異なるため、トリガーをそれに基づいて設定したくありません。

node('docker_builder') {
    git url: serviceRepo
    releaseVersion = getVersion()
    pipelineSpec = getPipelineSpec()
    sh "./gradlew clean build pushDockerImage"
}

ワークフロープラグインを使用するときにSCMポーリングを実現する方法についてのアイデアはありますか？

jenkins-workflow
19
gburton

私は多くの研究と実験でこの問題を解決しました。このドキュメントは私を正しい軌道に乗せました： https://github.com/jenkinsci/workflow-scm-step-plugin/blob/master/README.md 。それは言う：

ポーリングは複数のSCMにわたってサポートされ（1つ以上の変更により新しいビルドがトリガーされます）、ワークフローの最後のビルドで使用されたSCMに従って再度行われます。 "

つまり、SCMポーリングは引き続きJenkinsワークフローでサポートされますが、通常のフリースタイルプロジェクトとは異なり、SCMの変更のリスニングを開始する前に手動で一度実行する必要があります。 SCMはGroovyコードで定義されているため、これは理にかなっています。彼らは一度実行するまで知られていない。

これのトリッキーな要素の1つは、ワークフローで多くのSCMを定義できることです。たとえば、私は3つあります。1つはサービス自体、デプロイメントスクリプト、GroovyワークフローDSLです。デフォルトでは、これら3つのSCMのいずれかを変更すると、「SCMポーリング」オプションがビルドをトリガーするため、望ましくない場合があります。幸い、Groovyコードの「git」ステップで「poll：false」オプションを設定すると、そのリポジトリのポーリングが無効になります。 SCMからGroovy DSLを読み取っている場合は、Jenkins UIで[追加の動作]をクリックし、[コミット通知でビルドをトリガーしない]を追加することで、そのリポジトリのポーリングを無効にできます。

別のトリッキーな要素は、Stash Webフックプラグインがデフォルトで、JenkinsにヒットするRESTful URLにコミットのSHA1ハッシュコードを含めることです。残念ながら、Jenkinsは、定義した複数のSCMのいずれかをプルしようとするときに同じコミットコードを使用するというミスを犯します。もちろん、ハッシュコードは1つのSCMにのみ関連しているため、機能しません。 Stash Webフックプラグインで「SHA1ハッシュコードを除外する」を設定すると、この問題を回避できます。次に、Jenkinsは、各SCMで構築したブランチで最新のコミットを使用します。

33
gburton