はじめに
Pine & Path は庭の散策イベントを準備しています。ある編集者が開始時刻を遅らせるよう依頼し、その後、別の編集者が集合場所を変更しました。Jenkins はどちらの案内も準備して公開できますが、承認待ちの古い実行が、すでに来場者に届いた新しい告知を後から上書きしてしまう可能性があります。
この実習では、その上書きを実際に観察してから、古い待機中の実行を新しい実行が自動的に置き換えるように Pipeline を変更します。成果物は、最新の依頼にルート、予定表、案内の内容がすべて一致した、実際の来場者向け告知と、ダウンロードできる 7 ファイルのパックです。
前提知識は、Jenkins の基本的なページ操作と、短い Declarative Pipeline を見て理解できることです。パラメーター、承認による一時停止、同時実行の設定はここで説明します。Jenkins、コントローラーの 2 つのエグゼキューター、告知ツール、ローカルの Notice Desk は準備済みです。ソフトウェアのインストールや Web サイトの作成は行いません。両インターフェースは 1 台の練習用 VM 上で動きます。これは管理されたローカルの公開処理であり、本番のデプロイ基盤ではありません。所要時間は著者による見積もりで、初心者による実測値ではありません。
遅れた承認が告知を上書きする様子を観察する
このステップでは、最新の告知を公開し、その後で古い待機中の実行が上書きする様子を観察します。Notice Desk から始めてください。このインターフェースは開いたままにします。インターフェースを切り替えても、ビルドの再起動や告知のリセットは行われません。
通常の来場者向け機能を確認する
最初のイベントは庭の散策です。その View notice リンクを選びます。用意された告知の開始時刻は 10:00、集合場所は Community Gate です。Open the route を開いて 3 か所の立ち寄り地点を確認します。ブラウザーの Back 操作で告知に戻ります。Read visitor notes を開き、集合についての案内を読んで、もう一度 Back で戻ります。Schedule table は CSV ファイルです。各フィールドをコンマで区切った単純な表です。Notice details は JSON で、同じイベントを説明する、名前付きの値です。Preparation record は、このパックの準備方法を示します。この時点では PROVIDED BASELINE と正しく表示されています。セットアップは、あなたの代わりに Jenkins ジョブを実行してはいません。
ブラウザーの Back 操作で Notice Desk のホームページに戻ります。庭の散策の Download notice pack を選び、ZIP アーカイブを保存します。ZIP は複数のファイルをまとめる形式です。コンピューターのアーカイブツールで全体を新しいフォルダーに展開し、その index.html を開きます。隣接する 7 ファイルはすべて同じフォルダーに置いてください。ルート、スタイルシート、予定表、案内、JSON、準備記録は実際のローカルファイルです。index.html だけを移動すると、周囲のファイルへのリンクが壊れます。ブラウザーは CSV やテキストファイルを開く場合も、ダウンロードする場合もあります。どちらでも保存された内容を読むことができます。
Notice Desk のホームページに戻ります。別の Seed Swap の告知とダウンロードを確認してください。開始時刻は 11:00、集合場所は Potting Shed で、変更してはいけません。これから扱う編集者の依頼は、庭の散策だけに関するものです。
Read the editor requests を選びます。先の依頼の UPDATE 値は later-start で、10:30 に変更し、集合場所は Community Gate のままです。最新の依頼は new-meeting-point で、10:30 を維持し、Glasshouse Gate に集合します。ここでの「最新」は、後から届いた編集者の依頼を意味します。最後に完了したビルドのことではありません。
用意された Pipeline を読む
Jenkins に切り替えます。publish-walk-notice、Configure の順に開きます。Pipeline セクションと、その Script エディターを探してください。これは Declarative Pipeline です。外側の pipeline { ... } ブロックが作業を記述し、対応する波括弧が設定とステージをまとめます。
ジョブは agent any を使い、利用可能な準備済みノードにエグゼキューターとワークスペースを割り当てます。エグゼキューターは Jenkins が作業を実行するための枠、ワークスペースは 1 回の実行の作業ディレクトリです。この練習用コントローラーにはエグゼキューターが 2 つあるため、このジョブの 2 つの実行を重ねられます。作業ディレクトリは別々ですが、公開先は同じ庭の告知です。
parameters ブロックは、各ビルドで選択する値を定義します。choice は、2 つの編集者の依頼を UPDATE として提供します。booleanParam は HOLD_FOR_REVIEW をチェックボックスにします。チェックありは true、チェックなしは false です。params.HOLD_FOR_REVIEW は、その実行で選択した値を読み取ります。when 条件は、式が true の場合だけそのステージを実行します。
3 つのステージには、それぞれ別の目的があります。
- Prepare notice は、
deleteDir()で実行のワークスペースを消去し、shで用意された準備プログラムを呼び出して、notice-pack.zipをアーカイブします。archiveArtifactsは、そのファイルをそのまま Jenkins 標準のビルドに保存します。fingerprint: trueは、内容の識別情報と関連するビルドを記録します。準備とアーカイブは、来場者向け告知を変更しません。 - Review notice は、
inputで、チェックされた実行を公開前に一時停止します。Proceed リンクは次のステージへの進行を許可し、Abort はその実行を取り消します。これは意図した一時停止であり、接続失敗ではありません。 - Publish notice は、準備済みパックをローカルの Notice Desk に送ります。
post { always { ... } }ブロックは、中断を含め、実行が終わるとワークスペースを消去します。Jenkins にアーカイブしたファイルは、ワークスペースのクリーンアップ後も利用できます。
用意された準備・公開プログラムは、実際のビルドのパラメーターとアーカイブを読み取ります。これらのプログラム、すべてのステージ、レビュー条件、フィンガープリント記録、両方のクリーンアップ操作を維持してください。次のステップで変更するのは、重なる実行の扱いだけです。今は Script を変更せず、Save でジョブに戻ります。
古い実行を開始し、待機させる
publish-walk-notice ジョブページで Build with Parameters を選びます。UPDATE は later-start を選び、ラベルかチェックボックスをクリックして HOLD_FOR_REVIEW にチェックを入れます。Build を 1 回選びます。
Build History で開始したばかりの実行を開きます。まだ操作していないジョブでは #1 です。Console Output を開きます。Proceed と Abort のリンクがある Release this selected notice? を待ちます。そのまま待機させてください。コンソールには、準備とアーカイブがすでに報告されています。Publish notice はまだ実行されていないので、ジョブの共有の来場者向け告知は初期版のままです。
上部の publish-walk-notice のパンくずリストでジョブページに戻ります。これは Jenkins 内の移動であり、Notice Desk インターフェースへの切り替えとは異なります。待機中のコンソールに戻れるよう、古い実行の番号を記録してください。
もう一度 Build with Parameters を選びます。今度は new-meeting-point を選び、HOLD_FOR_REVIEW はチェックを外したままにします。Build を 1 回選びます。この新しい実行の Console Output を開き、Finished: SUCCESS を待ちます。まだ操作していなかったジョブでは #2 です。
Notice Desk に切り替え、ホームページを再読み込みします。庭の告知を開くと、10:30 と Glasshouse Gate が表示されるはずです。ルートと来場者向けの案内を開き、同じ集合場所を確認します。最新の編集者の依頼が、実際に公開されました。
古い実行を続行する
Jenkins に戻ります。ジョブに戻って、記録した古い実行とその Console Output を開き、Proceed リンクを選びます。Finished: SUCCESS を待ちます。古い表示のコンソールを開いている場合は、リンクを選ぶ前にその実行のコンソールを再読み込みしてください。ページの更新のために別のビルドを開始してはいけません。
Notice Desk に切り替え、再読み込みして、庭の告知をもう一度確認します。今度は 10:30、Community Gate と表示されます。これは想定した失敗です。古い実行が後で完了し、新しい依頼を上書きしました。Jenkins の両実行は成功しましたが、業務上の結果は古くなってしまいました。
この現在のパックを別のフォルダーにダウンロードします。publication.txt は古い Jenkins の実行を示し、ルート、予定表、案内はその古い依頼と一致します。Jenkins に戻り、その古いビルドの Build Artifacts リンクを開いて、Jenkins に保存された notice-pack.zip をダウンロードしてください。Notice Desk は、別の告知を裏で生成したのではなく、その実際の準備済みアーカイブを配信しました。
想定外に実行が待機している場合は、選択された Parameters とコンソールを確認します。入力プロンプトの Abort で誤って待機させた実行を取り消し、意図したパラメーターで再度開始できます。すべてのビルド履歴を残してください。プロンプトより前の失敗メッセージは、想定された承認の一時停止とは異なります。コンソールを読み、ステージを誤って編集していた場合は Configure に戻って復元します。
セルフチェック：実際に成功した両ビルド、先の実行の実際の承認、古くなった来場者向け結果を保持できています。別の Seed Swap の告知とダウンロードも引き続き機能します。後の修正で、この証拠を消してはいけません。
新しい実行で古い待機中の実行を置き換える
このステップでは、古い承認による最新の依頼の上書きを防ぎます。Jenkins の publish-walk-notice ジョブページから始めてください。
同じジョブの実行が重なる場合の方針を追加する
Pipeline の options ブロックは、実行の動作を制御します。disableConcurrentBuilds() だけを指定すると、現在の実行が終わるまで、新しい実行は待ち行列で待ちます。それでは、古い承認が主導権を持ったままです。代わりに abortPrevious: true を指定すると、この同じジョブの新しい実行が始まったとき、古い実行を中断します。true は真偽値であり、引用符付きのテキストではありません。コロンは、この名前付きオプションを設定に渡します。
Configure を選び、Pipeline → Script を探します。agent any の直後に、次の行を挿入してください。配置は外側の pipeline ブロック内で、parameters より前です。
options { disableConcurrentBuilds(abortPrevious: true) }
先頭は次のようになります。
pipeline {
agent any
options { disableConcurrentBuilds(abortPrevious: true) }
parameters {
この短い抜粋は配置を示しています。Script 全体をこの抜粋で置き換えないでください。既存のパラメーター、ステージ、アーカイブ処理、クリーンアップを維持します。Save を選びます。保存の変更が適用されるのは今後の実行です。効果を示すには、新しい 2 つの実行を開始する必要があります。
自動的な置き換えを観察する
ジョブページで Build with Parameters を選び、later-start を選択し、HOLD_FOR_REVIEW にチェックを入れて Build を選びます。新しく開始した古い側の実行の Console Output を開き、実際の Proceed / Abort プロンプトを待ちます。ここまで追加の試行なしに進めた場合は #3 です。待機させたままにしてください。手動で中止したり、続行したりしてはいけません。
パンくずリストでジョブに戻ります。Build with Parameters を選び、new-meeting-point を選択し、HOLD_FOR_REVIEW はチェックを外したまま、Build を選びます。この新しい側の実行のコンソールを開き、Finished: SUCCESS を待ちます。追加の試行なしに進めた場合は #4 です。
古い待機中の実行のコンソールを開き、再読み込みします。準備済みの Jenkins バージョンでは、この実行は NOT_BUILT で、Superseded by #... に新しい実行の番号が示されます。古い Publish notice ステージはスキップされ、クリーンアップは実行されました。灰色の状態表示だけでは不十分です。置き換えの原因を読み、新しいビルド番号と比較してください。古い入力は、もう承認待ちではありません。履歴のコンソールには、以前の Proceed/Abort のテキストが残る場合があります。置き換え後に、その古いリンクを使ってはいけません。
Superseded by #... とスキップされた公開ステージを読み、最後の NOT_BUILT の結果と比較してください。
ここでの NOT_BUILT は、何の作業も行われなかったという意味ではありません。古い実行は、一時停止の前にパックを準備してアーカイブしています。その Build Artifacts を開き、notice-pack.zip がまだダウンロードできることを確認してください。この方針が防いだのは、その古いパックの後からの公開です。両実行のワークスペースをクリーンアップしても、これらのアーカイブ済みファイルは残ります。
Notice Desk に切り替え、再読み込みして庭の告知を開きます。10:30、Glasshouse Gate が表示される必要があります。ルート、案内、予定表を読んでください。
10:30、Glasshouse Gate、ルートの最初の立ち寄り地点を合わせて確認します。ホームページに戻り、Seed Swap が引き続き 11:00、Potting Shed で始まることを確認してください。
誤って承認待ちにした実行の取消しを練習する
Jenkins に切り替えます。もう一度 later-start のビルドを、HOLD_FOR_REVIEW にチェックを入れて開始します。コンソールの入力プロンプトを待ち、Abort を選びます。これは意図的な手動取消しで、ABORTED で終了します。すでに観察した自動置き換えとは異なり、その証拠の代わりにはなりません。この実行は公開していないため、公開中の告知の集合場所は Glasshouse Gate のままです。
最後に new-meeting-point のビルドを、HOLD_FOR_REVIEW のチェックを外して開始し、SUCCESS を待ちます。これが、誤った依頼を一時停止または取り消した場合の復旧操作です。編集者のページを確認し、最新の依頼を選び、待機なしでビルドします。古い実行は残してください。履歴を削除すると、方針の動作の証拠も失われます。
Script の保存後、構文メッセージを伴う FAILURE になった場合は、波括弧の対応を確認し、options の行が pipeline 内にあり、stages やステージの steps 内にないことを確認します。Configure で修正して保存し、意図した 2 つの実行をもう一度開始してください。VM のリセットや、用意されたツールの変更は行いません。追加の失敗した試行は、履歴に残してかまいません。
最終成果物を保存して確認する
Notice Desk に切り替えます。再読み込みして、庭の notice pack をダウンロードします。以前のダウンロードのファイルと混ぜず、新しいフォルダーに保存してください。ZIP 全体を展開し、index.html を開きます。Glasshouse Gate、10:30、イラスト付きのルート、3 か所すべての立ち寄り地点を確認します。Read visitor notes、Schedule table、Notice details、Preparation record を開きます。CSV と JSON はページと一致し、publication.txt は最後に成功した Jenkins のジョブとビルドを示す必要があります。フォルダー全体は、Jenkins や Notice Desk なしでローカルで機能します。ローカルファイルの表示を切り替える間は、ブラウザーの Back 操作を使ってください。
Jenkins で、対応する成功ビルドと Build Artifacts を開き、notice-pack.zip をダウンロードします。展開した 7 ファイルは、Notice Desk のダウンロードと一致する必要があります。Jenkins 標準のアーカイブは、ビルドが何を準備したかを記録し、Notice Desk は実際に何が公開されたかを示します。
セルフチェック：保存した方針が有効で、実際の新しい実行が、入力待ちで一時停止した古い実行を自動的に置き換え、来場者には最新の依頼の実際のファイルが届いています。この一時停止した実行と新しい実行の組は、保存したこの Script で実行されている必要があります。完了済みの最新の実行は、それ自身が最新内容の公開に成功している必要があります。誤った公開や公開のスキップの後は、Script を復元して再実行してください。さらに動作を変えた場合は、一時停止させる古い実行と、それを置き換える新しい実行の組を、改めて実行して示します。すべてのビルド履歴、以前のアーカイブ、準備・レビュー・公開・クリーンアップの動作、無関係なイベントは維持します。
この設定が影響するのは、1 つのジョブ内で重なる実行です。中断前に行われた公開を取り消したり、異なるジョブを調整したり、すべての本番デプロイを安全に中止できるようにしたりするものではありません。ここでは、古い実行が唯一の公開ステップより前に一時停止するため、境界が明確です。
まとめ
実際の来場者向けの結果を、Jenkins の実行動作に結び付けました。古い承認が新しい告知を上書きする状況を再現し、disableConcurrentBuilds(abortPrevious: true) を使って、新しい実行が同じジョブの古い待機中の実行を中断するようにしました。準備と公開、Jenkins 標準の置き換えと手動取消し、アーカイブ済みファイルとワークスペース内のファイルを区別しました。
最終成果物は、オフラインのルート、予定表、案内と一致する、最新の庭の告知です。保持した履歴から、成功したビルドによって、意図した更新が実際に来場者に届いたことを確認できます。
