問題タブ [jenkins-job-dsl]

job dsl プラグインを使用して jenkins ジョブを生成しています。ジョブ DSL プラグインのソナー実装で問題が発生しています。Flexible Publish プラグインを使用して、ソナーを実行するための条件を提供しています。つまり、ワークスペースで pom.xml が見つかった場合は、ソナーを実行します。問題は、ソナー変数「 jobAdditionalProperties 」を設定したいのですが、その変数はまだジョブ DSL プラグインでサポートされていないことです。私がこれまでに得たもの：

ドキュメントに従って、configureメソッドを使用しようとしました：

しかし、xml は条件を使用して柔軟なパブリッシュ プラグインでネストされており、xml は適切な場所に生成されないため、これは機能しません。XML ツリーは次のようになります。

誰でもこれを解決する方法の手がかりを得ましたか?

を使用するジョブを生成するために DSL を使用しようとしていますcopyArtifacts。Copy artifact from another project以下を使用して基本を生成できました。

Which buildただし、 、Artifacts to copyおよびも指定できる必要がありますTarget directory。Closure copyArtifactClosureこの情報を指定する方法がよくわかりません。例は見つかりませんでした。

HTTPS 経由で xml ストリームを読み取りたい。Web サーバーには、独自に作成した非公式の CA によって署名された証明書があります。

Groovy Job DSL スクリプトを機能させるには、CA 証明書をインポートする必要があることはわかっています。

CA 証明書をどこにインポートする必要がありますか、またはそれを機能させるために独自の trustStore を定義するにはどうすればよいですか?

私が前に試したこと：

• keytool を使用して CA 証明書を C:\Program Files (x86)\Java\jre1.8.0_40\lib\security\cacert にインポートする
• keytool を使用して CA 証明書を C:\Program Files (x86)\jenkins\jre\lib\security\cacert にインポートする

CA証明書をcacert trustStoreにインポートした後、groovyConsoleとの接続を試みると、すべてが機能しますが、Jenkinsでは機能しません。

そのため、ジョブ DSL スクリプトに trustStore を設定しようとしましたが、成功しませんでした。まだ証明書チェーンエラー例外を受け取ります:

コンソール スニペット:

アップデート：

また、Jenkins JRE で groovyConsole を開始しました。それも機能しています。そのため、cacerts キーストアには、機能する CA 証明書が含まれています。しかし、Jenkins スクリプト コンソールまたはジョブ DSL プラグインで機能しないのはなぜですか。ここで何が問題なのですか？

TestNG、Jenkins、および job-dsl-plugin を使用しています。

私のプロジェクトには、テスト用の TestNG XML テストスイートがたくさんあります。私が欲しいのは、これらの各スイートを通過し、それらのジョブを作成するスクリプトです。

私のテスト スイートは次のようにフォーマットされています。

そのため、ジョブの DSL スクリプトは、testsuites ディレクトリ内の各テストを再帰的に実行し、これらのファイルの XML を取得して解析し、それぞれに対してジョブを作成する必要があります。

1. レポにアクセス
2. testsuites ディレクトリ内のすべての XML ファイルを再帰的に読み取る
   1. スイートの名前を取得 -> Jenkins ジョブの名前
   2. このテストスイートへのパスを取得します ->-Dtestngfile=<path>
3. これらのそれぞれのジョブを作成します

ジョブの作成と、DSL プラグインを使用して新しく作成されたビューへの追加に関する次の質問を見つけました。

新しく作成されたビューにジョブを追加しています。

DSL プラグインを使用して、作成したジョブを既存のビューに追加するにはどうすればよいですか? ドキュメントにヒントが見つかりませんでした。解決策が見えないのは明らかすぎるのでしょうか？

私は読みましたが、ビューが既に存在する場合、ビューを作成すると再作成されます。このビューの下にある既存のプロジェクトにとって、それはどういう意味ですか?

ご協力いただきありがとうございます。

Jenkins DSL プラグインを使用して、git プロジェクトのすべてのブランチのビルド ジョブを自動的に作成しています。DSL プラグインは Web フックによってトリガーされるため、新しいブランチが作成された直後に実行されます。各ブランチに対して生成されたビルド ジョブも、Web フックによってトリガーされるように構成されています。

現在のセットアップの問題は、ビルドが 2 回目のコミット後にのみ実行されることです。最初のコミットは、Jenkins DSL プラグインをトリガーして、それぞれの Jenkins ジョブを作成し、2 番目のコミットは、新しく作成されたジョブをトリガーします。

DSL プラグインによって作成された直後に Jenkins ジョブを開始する方法はありますか? 現在思いつくことができる唯一のことは、追加のビルド スケジューリングを追加することですが、不要なポーリングを防ぐためだけに Web フックを使用したいと考えています。

Jenkins Job DSL スクリプトを作成しようとしていますが、できるだけ宣言的/DRY-ly に作成したいと考えています。Jenkins タスクは、MultiJob を介して他のいくつかのタスクを呼び出しています。私はもともと次のようなGroovyを持っています（他の場所で参照されているため、すべてがクラス内に含まれています）：

多くの重複を含むジョブの作成を抽象化したいと思います。私はこのような奇妙なものになってしまいました：

これは、おそらく完全に非慣用的な Groovy であり (このdef self = ({ owner })()ようなものはすべて私には合いません)、まったく機能しません。

基本的に、すべての変数を引数として明示的に渡すことなくcallingClosure、 のスコープ内のすべての変数をクロージャーに渡したいと思います。job_config(引数のマップを明示的に渡すことは機能しますが、多くの引数があると扱いにくくなります。) どうすればこれを行うことができますか?

(PS: 現在、Groovy はcommit_a内部の変数をjob_configから来ているものとして解決しようとしていますがjavaposse.jobdsl.dsl.helpers.step.PhaseContext、これは奇妙だと思います。デリゲートをその内部のクロージャーに明示的に設定しませんでしたPhaseContextか?)

編集:別の SO questionから、代わりにphase= delegate(デフォルトは?) を設定して問題ないようです。は のプロパティであり、その親 (?) ではないため、これもよくわかりません。owner({ owner })()jobPhaseContext

Jenkins Job DSL プラグインを使用するコードを再利用可能な部分に分割しようとしていますが、私の質問は Groovy に一般的であり、Jenkins 固有ではないと思われます。たとえば、このブロックの一部を再利用したい:

ユーティリティメソッドに名前と説明を配置することにより（明らかに、実際にはそれ以上のことをしたいと考えています）。ただし、現在のスコープのクロージャーを作成するための適切な構文が見つかりません。これが私がそれがどのように見えるべきだと思うかです：

(おそらく Closure.delegate = this どこかで)

ただし、それは閉鎖には機能しません。ここに示すように、メソッドに対して機能しています: https://dzone.com/articles/groovy-closures-owner-delegate

説明のために、可能な構文の 3 つの組み合わせを示すテストを次に示します。

クロージャがメイン クラスにないというエラーが表示されます (つまり、test.groovy のテスト): Method not found in class test@60611244 by name myClosure

デリゲートを「これ」に変更しようとしたり、ルックアップ戦略を変更しようとしたりしました。おそらく基本的なものが欠けています。

jenkins dsl プラグインを使用して、プロジェクトのすべてのブランチに対して jenkins ジョブを生成しています。ブランチが削除されると、dsl プラグインはそれぞれの jenkins ジョブも削除します。

ただし問題は、ワークスペースがジョブと一緒に削除されないため、最終的にディスクが乱雑になることです。私が見つけた 1 つの解決策は、すべてのワークスペースを定期的に一覧表示し、同じ名前のジェンキンス ジョブが存在するかどうかを確認することです。

dsl プラグインによって削除されたばかりの jenkins ジョブの古いワークスペースを自動的に削除する、より洗練されたソリューションがあるのではないかと考えていました。