ステップはシェルスクリプトを呼び出して（例えば、テストサーバーにアーティファクトをインストールするなど）、技術的な理由で失敗します（ネットワークが機能しない、データベースが破損するなど）。考えられる反応：Jenkinsステップ（Jenkinsパイプライン）で技術的なエラーを処理します。
すべてのジョブを失敗します。良いアイデアではない、なぜなら、前のステップを何の理由もなく繰り返す必要があるからです（これらのステップには手動のステップも含めることができます）。
たとえば、 5分待つ。時々問題を解決することができましたが、問題が誤った構成によって引き起こされた場合は無限ループにつながる可能性があります。
続行するか、中止するかをユーザーに確認します。最も柔軟なアプローチですが、（予想外の）必要性は相互作用を使用します。
Jenkinsには標準的なソリューションがありますか？
ジョブ全体を失敗します。良いアイデアではない、なぜなら、前のステップを何の理由もなく繰り返す必要があるからです（これらのステップには手動のステップも含めることができます）。
問題の重大度をどのようにランク付けするかによって異なります。私は個人的にビルドの問題があればそれを記録し、失敗し、誰にでも知っておく必要がある人に通知します。しかし、もしあなたがそれが過度のものだと感じるなら、あなたは他の何かを試したいかもしれません。
たとえば、 5分待つ。時々問題を解決することができましたが、問題が誤った構成によって引き起こされた場合は無限ループにつながる可能性があります。
あなたはJenkinsfileでset a timeoutは後に放棄することができ、時間を言うか、しかし限り、あなたは仕事が取るべきだと思います。このようにして、何度か再試行しても、仕事が止まった場合にはその仕事の終了を保証します。
続行するか、中止するかをユーザーに確認します。最も柔軟なアプローチですが、（予想外の）必要性は相互作用を使用します。
ユーザーインタラクションは、特に発生するタイミングがわからない場合や、ジョブが午後10時〜午後5時の間に実行されるようにスケジュールされている場合には便利です。
すべてのオプションのうち、2番目のオプションが最も良いと思われます。何度か再試行し、それがうまくいかない場合は、何が起こったかを記録し、失敗して誰かに通知してください。それはあなたの散発的な技術的な問題をカバーする必要があります。また、再試行がうまくいかない場合は、修正するより大きな問題があることを示すことができます。