19

通常のフリースタイル プロジェクトでは、リリースしたい Git リポジトリを指すように SCM プラグインを構成し、「Poll 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 ポーリングを実現する方法について何かアイデアはありますか?

4

1 に答える 1

33

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

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

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

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

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

于 2015-06-30T20:45:09.647 に答える