これを使用して、ジェンキンスジョブを開始できます。
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
このジョブからconsoleTextを取得することもできます:
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/lastBuild/consoleText"
ただし、複数のジョブを連続して実行した場合、これはスケーリングしません。最初のcurlコマンドには次のような戻り値があることに気づきました。
Location: http://jenkins_srv:8080/queue/item/123/
123
がジョブキューIDであると想定しています。
私の質問は、ジョブ121
、122
、および123
を連続してキューに入れる場合、ジョブキューアイテム122
のステータスをチェックするために何を使用するかです。また、ジョブキューアイテム122
から最終的に生じた実際のビルドIDを決定するために何を使用しますか?
前もって感謝します。
Kdawgの回答を選択しました。これは、必要な方向に導くのに役立ちました。ありがとうございました!
また、自分の回答も含めています。これは、実装したソリューションがKdawgの回答とは異なり、他の人にとっても価値があると感じているためです。
最初に、私はジェンキンスに新しいです。ですから、話を間違えた場合は、遠慮なく訂正してください。次に、Jenkinsの「キューアイテム」とJenkinsの「ビルドジョブ」に違いがあるという点で、少し習得しました。 「キューアイテム」が作成された瞬間、開始されたビルドジョブがないため、「ビルドジョブ」IDはありません。また、ビルドジョブが開始されると、キューアイテムは削除されるまで5分かかります。
これらのタスクを実行すると:
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
Jenkinsは、キューで実行される3つのビルドジョブをスケジュールします。これらは「キューアイテム」になります。これらの「キューアイテム」には「キューID」があります。元の質問の例で、これらの3つのcurlコマンドが「キューID」121
、122
、&123
を使用して「キューアイテム」を作成するとします。
何でこれが大切ですか?
Jenkinsサーバーの負荷に応じて、キューに入れられたアイテムがすぐに実行される場合とされない場合があります。それがすぐに実行される場合、Kdawgの答えは間違いなく正しいです。彼のコマンドを実行する:
curl -X GET http://jenkins_srv:8080/queue/item/121/api/json?pretty=true --user name:pass
curl -X GET http://jenkins_srv:8080/queue/item/122/api/json?pretty=true --user name:pass
curl -X GET http://jenkins_srv:8080/queue/item/123/api/json?pretty=true --user name:pass
これにより、各「キューアイテム」に関するキュー情報が取得されます。ビルドジョブが開始されている場合は、返される結果に「ビルドジョブ」IDを取得する方法が確実にあります。ビルドジョブがまだ開始されていない場合、この情報は空白になります。
これが、私が価値を付加すると感じる追加の部分です。
ビルドジョブが開始されると、Kdawgの回答の情報が3つのcurl -X GET
コマンドへの応答に入力されます。また、デフォルトでは、Jenkinsは「キューアイテム」を5分ごとに清掃(ガベージコレクション、独自の用語を選択)するように設計されています。つまり、「キューアイテム」IDだけがあり、5分のデータ保持期間が経過した場合、「キューアイテム」IDから「ビルドジョブ」IDを取得するための別のメカニズムが必要になります。
したがって、私の場合は、Jenkinsをフロントエンドとして使用し、Ansibleをバックエンドで使用してサーバー構成とアプリケーションのデプロイメントを実行しています。これらのアプリケーションのデプロイメントには、「キューアイテム」の5分のデータ保持期間をはるかに超える30分以上かかるものもあります。
だから私が解決しなければならなかった問題は、私が持っているすべてが「キューアイテム」IDである場合、チェックするタイミングに関係なく、「ビルドジョブ」IDを数秒後または数時間後にどうやって見つけるのですか?
これが私の解決策です(私はXML出力が必要であることに注意してください、FYI)。
私はこのコマンドを実行しました:
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
このコマンドは次の情報を返します。
Runtime responseHeaders Date: Day, ## Non Year xx:yy:zz GMT
X-Content-Type-Options: nosniff
Location: http://jenkins_srv:port/queue/item/123/
Content-Length: 0
Server: Jetty(9.4.z-SNAPSHOT)
ここから、Location
フィールドから123
を解析できます。
その後、10秒間寝た。スリープ後、このコマンドを10秒ループで実行します。
curl -X GET http://jenkins_srv:8080/queue/item/123/api/xml
私は次のいずれかになるまでそれを行いました:
この方法のループは、キューリクエストの処理が遅い負荷のかかったJenkinsサーバーを処理します。したがって、おそらく10分が経過しても、私のアプローチは、自動化アプローチがジョブをキューに入れて実行したユースケースを引き続き処理しますが、データ保持ウィンドウの外でJenkinsをチェックしています。この場合、次のコマンドを実行します。
curl -X GET http://jenkins_srv:port/job/MY_JOB/api/xml?tree=builds[id,number,result,queueId]&xpath=//build[queueId=123]
これは、以下に示すように、queueId
の123
も含む「ビルドジョブ」のXML情報を返します。
<?xml version="1.0"?>
<build _class="hudson.model.FreeStyleBuild">
<id>456</id>
<number>456</number>
<queueId>123</queueId>
<result>SUCCESS</result>
</build>
このようにして、開始時とチェックバック時の時間差に関係なく、「キューアイテム」IDのみを保持しながら、「ビルドジョブ」IDを確実に取得することができました。
驚いたことに、Jenkinsは一意のIDでその結論へのリクエストを追跡していません。
キューに入れられたアイテムとビルドアイテムの間で永続する1つの要素は、パラメーターのリストです。ジョブの構成を変更する機能/権限がある場合は、オプションのパラメーターREQUEST_IDを追加します。これは、クライアントが空中から取得して(UUIDなど)、RESTを介して渡します。次に、キューをクイズしてREQUEST_IDを持つものを探し、ビルドのリストをクイズしてREQUEST_IDを持つものを探すことができます。