Packer: --Vagrantのようなエラー時の破壊はありません

これは合理的に聞こえます。 -debugフラグは確かにここでは正しいアプローチだと思いますが、おそらく-debugフラグは次のようなオプションを許可する必要があります。

• すべてのステップをステップスルーします
• エラーが発生するまで続行します
• クリーンアップ手順が始まるまで続けます

エラーが発生するまで続行し、VMを破棄しないオプションが非常に便利だと思います

誰かが私にこれを実装するために探し始める場所についてのいくつかのポインタを与えることができれば、私はこれをオプションとして追加することに少し時間をかけることができるかもしれません

これは私にとっても非常に便利です。

@timmow特定のフラグが設定されている場合は、各ビルダーのインスタンス作成クリーンアップ手順を変更して何もしないようにする必要がある場合があります（たとえば、https：//github.com/mitchellh/packer/blob/master/builder/amazon/common/step_run_source_instance.go ＃L122）

すべてのステップをくまなく調べて、何もしないことが適切な場所を見つけるのは、ある程度の作業になります。

私がちょうど持っていたアイデアは、クリーンアップステップを処理する前にユーザー入力を待機するフラグを与えることでした。 そうすれば、デバッグを実行できます。たとえば、Enterキーを押すと、packerがクリーンアップを処理します。

何か助けがあれば、ここで私にpingしてください。

ここでFILOの方法で行われるfyihttps ：//github.com/mitchellh/multistep/blob/master/basic_runner.go#L71

基本ランナーを拡張する必要があるかもしれません（debuggable_runner？）

この--no-destroy-on-errorタイプの構成のクリーンアップ手順を基本的にスキップする、ある種のステップ「スキップ」機能を下に追加すると便利です。 また、 sを押してスキップするなど、 -debugモードでいくつかのクールな機能をインタラクティブに有効にします。

デバッグの「一時停止」と同様に、 -pause-on-errorようなオプションが有益だと思います。

こんにちは、この問題はこのコミットhttps://github.com/mitchellh/packer/commit/2ed7c3f65cc2e0a14d39d8934ef1168f8192bb08によって修正されているようですが、マスターブランチのHEADに変更はありません。 どこで、なぜ消えたのですか？

私もこれが本当に必要です。

この機能を利用したいという希望はありますか？ 2ed7c3fまたはそのバリエーションをマージするには、何をする必要がありますか？

ええ、私もこのオプションを使用できます。 コミットされたのに消えたようです。

これに関する更新はありますか？

私もこれが大好きです。 問題のデバッグにどれだけの時間を費やし、エラーが何度も発生するまでに長いVM作成プロセスを実行する必要があるかはわかりません。 VMを維持できることは、大きなメリットになります。

これ（または同様の機能）がメインにマージされるときにETAはありますか？ Packerを使用して、ベースのVagrantボックスの一部としてVisual StudioがインストールされたVMを構築しようとしていますが、手順が失敗する理由を確認する前に、VMを破壊しないようにする必要があります。 --debugを介して各ステップを確認する必要はありません。

-debugオプションは私が分析しようとしている失敗を抑制するので、これに対する別の投票。

マシンが失敗する前に、マシンの最終状態をデバッグしようとすると、非常に多くの時間がかかります。 -debugスイッチはそれをカットしません-私はそれを通常のプロセスで実行し、失敗した後も作業フォルダーをそのままにして、ログと状態で診断できるようにします。 ある種の保存動作状態の切り替えを本当に楽しみにしています。

この機能のもう1つの+1は、非常に役立ちます。

+1同様の問題が発生し、最終状態をデバッグし、プロビジョニングスクリプトを微調整してから、ビルドを再度実行して、デバッグ手順で手動でEnterキーを押すのではなく、プロセスが修正されたかどうかを確認します。

この機能のための別の+1。 これに何が起こったのかを知っておくといいですか？ チームの誰も答えませんでした。 痛くないプレートにステップアップしてください。 笑！ 私はパッカーに全く新しいです。 私は1.5時間のISOビルドの最後尾にいましたが、これが起こりました。 テストとデバッグは、完全に甘いアプリケーションをフルストリームにするために最も重要です。

ここでも+1、ヘッドレスでイメージを作成するため、-debugで手動でステップスルーする必要があるのは良くありませんが、障害のあるイメージを検査できるのは素晴らしいことです。

：+1：私もこの機能が好きです

+1この機能は素晴らしいでしょう！

＃1687に関連するか、おそらく複製されます

+1 @errorを削除せずにVMをそのままにして

+1これは非常に便利です

Packerのみ失敗した場合に、プロビジョニングのデバッグに役立つ+1

+1私は同じ船に乗っています。 Windows VMの再作成に数え切れないほどの時間を費やしましたが、プロビジョニング手順でChefエラーが発生し、VMが削除されたときにVMをデバッグする方法がありませんでした。 失敗時にすべてを削除しないオプションがあるようにしてください。

この問題が2年間続いているのを見て、これが修正されることを期待していません。 私は本当にPackerを好きにしようとしていますが、実際に結果を使用するよりも、ビルドステップを待つことに多くの時間を費やすことになります。

Pleeeeeaseeeeeee +1

+1

+1

+1

これについての議論が何であるか疑問に思い、グーグルを介してこの問題を見つけました。 機能が存在しなかったときに悲しくなりました。

こんにちは開発者、私はこのスレッドを再訪し、packerを効果的に使用し続けることができたが、この1つのバグがシステムの開発を大幅に遅らせていると言っても過言ではありません。 私たちはそれを行うことができますが、スタッフがこの問題について@mitchellhでいくつかのガイダンスを提供できれば幸いです。 正しい方向を示すことができれば、解決策を提供する時間さえあるかもしれませんが、うまくいけば、あなたの応答またはあなたのチームの誰かを待ちます。 でも素晴らしいツールをありがとう。 私は間違いなくあなたとあなたのチームにこの製品がどれほど素晴らしいと思うかを知ってもらいたいです。

必要な機能のすべての+1電子メール通知に飽きたので;-)、コードベースを掘り下げて、最初の実装を追加しました。 注-これはまだテストされていません...そしてそれが正しく機能するかどうかさえわかりません。 ソースからビルドしようとすると、Packerがgithubから自己参照するという興味深い問題が発生し、このコードが正しくビルドされなくなります。 GoPathのpackerソースフォルダーを、このリポジトリをダウンロードするフォルダーに一時的にリンクする必要があります（または、プルリクエストをテストして送信するのを待ちます）。

https://github.com/jcoutch/packer

これがデフォルトの動作ではないという事実は、私のフランス語を許せば、完全に正気ではありません。 インストールスクリプトにタイプミスをしましたか？ さて、あなたのすべての仕事を便利に_破壊し、あなたの人生のその時間を決して戻さないようにしましょう。 以上。 オーバー。 再び。_

このツールを最も単純な例以外の目的で使用する_文字通りすべての人_が、_使用するたびに_この問題に直面していると思います。 明らかに、この機能には大きな需要がありますが、2年経ってもまだ実装されていません。

絶対に驚異的です。

+1

男、それは卑劣なコメントでした。 昨日は機嫌が悪かったのですが、時間の浪費は多くの時間とお金を要し始めています。

@ jcoutch-共有できるビルドはありますか？

私は自分のマシンにOSXビルドを持っていますが、それをテストする機会がありませんでした
まだ動作します。 暇なときにこれに取り組んでいます...私はあまりしていませんでした
最近スペア。 言うまでもなく、これはGoでの私の最初の経験です（かなり
面白い言語です。）今週の終わりまでにテストしてみます。
すべてが良さそうな場合は、プルリクエストを送信します。 私もしようとします
OSXとWindowsのビルドを投稿して、安定していることがわかったら、他の人がテストできるようにします。

2015年9月23日水曜日、午後5時14分リッチジョーンズ[email protected]は次のように書いています。

男、それは卑劣なコメントでした。 昨日は機嫌が悪かったが、この間ずっと
消耗は多くの時間とお金を要し始めています。

@ jcouth-共有できるビルドはありますか？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/mitchellh/packer/issues/409#issuecomment-142730452 。

Pleeeease !! :-D

Ansibleで実行しようとしていますが、機能せず、エラー後にKVMゲストがなくなったため、そこに移動して何が問題なのかを確認することはできません...

乾杯！

多くが必要です。 ありがとう。

簡単に確認できるように、適切な行末を持つ示します： https ：

このパッチは、プリプロセッサに障害が発生した場合にのみ削除を防止し、ビルダー（およびそのプロビジョナー）に障害が発生した場合にアーティファクトを保持しません。

編集：それは意図のようですが、実際には何もしませんが、それを満たすために簡単に修正することができます。

ええ、私はこのスレッドに返信する機会がありませんでした。 やっとやってみた
落下するプロビジョナーで私の変更を出します...それは私のようには機能しません
意図されました。 コードを詳しく見ると、ビルダーが処理しているように見えます
コードの代わりに、プロビジョニングの失敗によるアーティファクトの削除I
変更されました。

土、2015年10月3日には、9:37 Orivej Deshの[email protected]は書きました：

これが@jcoutchhttps ：//github.com/jcoutchパッチで適切な行があります
簡単に確認できるエンディング： orivej @ 23bbd4d
https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/mitchellh/packer/issues/409#issuecomment-145249481 。

ここでhttps://github.com/orivej/multistep/commit/e02bce9811c65138ea2e84c7162cd8769f35858fは、最初の失敗後に1回だけ停止するように--debugを再定義する概念実証です。 2回目のクリーンアップの前ではなく、最初のクリーンアップの前に停止するには、 https：//github.com/mitchellh/multistep/pull/5が必要です。 この動作は＃1687で提案されました。 （これは概念実証ではありませんが、＃1687で提案されているように--debugを再定義しても問題がない場合の解決策です。）

-debugモードで失敗したビルドのアーティファクトを保持するための+1。

私はパッチを使ってしばらくpackerを実行していて、 -debugなしでそれを開始する理由はありません

+1

私が投稿したリンクが、パッカー用ではなく、マルチステップ用のパッチであることに気づきました。 -debug実行しているときに、エラー時にパッカーを一時停止させる修正は、 https：//github.com/orivej/packer/tree/debug-on-errorにあります。

@orivej非破壊動作パッチをテストしたい場合、どのパッチから始めるべきですか？ https://github.com/orivej/packer/commit/a713a4698831a8dfcd48484dc4675631779b6840 ？

はい、 orivej @ a713a46という1つのコミットがあり
https://github.com/mitchellh/multistep/pull/5からgithub.com/mitchellh/multistepパッチも必要です。そうしないと、最後のステップを破棄した後、packerが一時停止します。

@orivej OSX用のパッチが適用されたバイナリはありますか？ Gentoo Linuxボックスをビルドする際の小さなエラーのためにビルドプロセス全体を再起動することは、非常に苦痛です（時間がかかります）。 失敗した後にボックスをロードして、何が悪いのかを見つける可能性があることは私にとって必須です。

失敗したステップを中止する代わりに再試行するオプションを追加しましたが、これが成功したとしても、ビルド全体が失敗する可能性があります。 また、エラーが発生しなかった場合、packerは入力を確実に処理せず、ユーザーは複数回応答する必要がある場合があります。

この変更は、パッチが適用されたマルチステップに依存せず、ブランチ、コミットに存在します。

ここにバイナリをアップロードしました： https ： debug-on-error-2 ）。

失敗した後にボックスをロードして、何が悪いのかを見つける可能性があることは私にとって必須です。

私のパッチはロード可能なボックスを保持しませんが、代わりにビルドを手動で終了するまで現在のボックスを存続させて、SSHで接続してデバッグを実行できるようにします（ -debug packerを呼び出す場合） -debugオプション）。

フィードバックをありがとう、@ orivej。

私のパッチはロード可能なボックスを保持しませんが、代わりに、ビルドを手動で終了するまで現在のボックスを存続させて、SSHで接続してデバッグを実行できるようにします（-debugオプションを指定してpackerを呼び出す場合）。

--debugのデフォルトのpackerビルドは、環境が破壊される前に一時停止し、説明したようにデバッグするオプションを提供します。 そのために、 "headless": falseを使用します。 パッチのプロセスはどのように異なりますか？

• すべてのステップの後で一時停止するのではなく、ステップが失敗した後にのみパッカーを一時停止します。
• 失敗したステップの後、packerがクリーンアップする前に一時停止します。 （最も問題のあるプロビジョニング手順ではクリーンアップが行われないため、なぜこれが必要なのかは覚えていません。）
• パッチの第2版では、失敗したステップを再試行できます。 （プロビジョニングが失敗すると、すべてのプロビジョニング担当者が再実行されます。）

＃2608が、古いバージョンのpackerから新しい組み込みプラグインにプラグインを優先するという不幸な決定をしたことに気づきました。そのため、私のビルドのpacker（または、作成者がこの動作を再考しない限り、packerの将来のリリース）を使用するには、すべてを削除する必要があります。名前がpacker-始まるバイナリ。

信頼性の低い入力処理も＃2608のアーティファクトです。修正できるかどうかを確認します。

信頼性の低い入力処理は、組み込みプラグインの追加の初期化、特にmain.go setupStdin()によって引き起こされます。 この呼び出しはとにかく宣言された目的を果たすことができないように思われるので、私は影響なしにそれを無効にすることができ、バイナリを再構築しました。

エラー時にVMを停止または破棄せずに、単にpackerを終了できると、非常に便利です。 これは、通常最もカスタムロジックを含むプロビジョニングコンポーネントで特に重要です。 ボックスにSSHで接続して元のスクリプトを再実行したり、変更したスクリプトやレシピをテスト用に試したりできると、実際にエラーが発生した原因と修正内容について、すばやく貴重な洞察を得ることができます。 パッカービルド全体を実行するには時間がかかりすぎて、最も単純なトラブルシューティングでもそれを要求することはできません。

-debugフラグは便利ですが、プロセスが手動になります。 多くの場合、無人ビルドを実行すると便利ですが、エラーが発生したときにビルドを終了し、システムを原因の調査と修正が可能な状態のままにします。

：+1： -debugが成功するか失敗するかに関係なく、インスタンスでスクリプト/デバッグを再生できるように、インスタンスを実行し続けるオプションが必要です。これが何らかの理由でAMIイメージのキャプチャに干渉しない限り。

+1

+1 ..とても便利なので、これが約2。5年後になることに驚いています。 これにより、Packerビルドのトラブルシューティングが非常に簡単になります。

chef-clientが起動する前にインスタンスで終了保護を使用することで、AWSでこれを克服することができました。 それはまともなオプションではありませんが、ちょっとそれは動作します。 その他のオプション:)

+ 500-なぜこの機能がまだないのですか？

たぶん私たちは開発者として、文句を言う代わりに手を汚そうとすることができるでしょうか？

機能のリクエストはこれ以上ないほど簡単です。

• 新しいコマンドラインオプションを読み取る（ --no-destroy-on-error ）
• 控えめなifを適切な場所に追加します。 擬似コード：

unless no_destroy_on_error # add this conditional <<<<<<<<<
   perform_cleanup
end

試してみます。 そしてそれがうまくいくなら、私はそれを共有しません（主に架空の要求/苦情を避けるために）。 努力は良いことです。

@vemv 、私はすでにhttps://github.com/orivej/packer/commits/debug-on-error-2で2つのコミットでこの問題を本質的に解決しました

@orivejすごい！ 私は--pause-on-errorを追加することを計画しており、これが最善の方法だと思います（ステップが失敗した場合は、キーストロークを待ってからクリーンアップし、ユーザーがログインしてトラブルシューティングできるようにします）。

コードを使ってPRを開いていただければ、詳細について話し合うことができます。
CC @cbednarski

@vemv私はこの問題を数年間フォローしています。 私は自分自身でしか話すことができませんが、Goについてはまったく知りません。少なくとも、コードが何をするのかを考えて理解する以上のことはありません。 適切にテストすることは言うまでもなく、Packerのように広く使用されているもののコードを書くのは気が進まないでしょう。

@orivejと@ rickard-von-essenは、自動ツール（JenkinsまたはTravisCI）でのみPackerを使用しているため、ユーザー入力が必要なものは実際には機能しません。 私の立場には他にもたくさんの人がいることを私は知っています。 私が本当に望んでいるのは、（1）出力の冗長性を高め、（2）ソースマシン（EC2、VMWareなど）を実行したままにして、人間が後で検査できるようにすることだと思います。ジョブが失敗しました。

現在、デバッグはステップ間で一時停止し、続行するにはEnterキーを押す必要があります。失敗しようとしているステップがわかっている限り、デバッグのためにVMをそこに「保持」するだけで済みますが、明らかにそれはそれほど良くありません。 完全に失敗した状態を調べることができるように、テンプレートですべてのステップを実行する必要があります。

私の：+1：を追加するだけです。 私は本当にこの機能を使うことができました。

@jantmanプロセスが失敗して入力を取得できない場合（たとえば、 /dev/nullからの入力の場合）、 packer -debugクリーンアップをスキップさせます。 パッカーの実行シーケンスは、すべてのステップが後でクリーンアップされる可能性があるという考えに基づいて構築されているため、突然終了すると、システムはパッカーが単独で処理できない状態になります（たとえば、出力ディレクトリに文句を言う）すでに存在しているため）、プロセスを繰り返し可能にする方法を理解する必要がありますが、これはおそらく簡単です。

@ rickard-von-essenパッチを更新し（新しいプロバイダーを追加し）、本日遅くにプルリクエストを行います。

@DarwinJSからhttps://github.com/mitchellh/packer/issues/3445#issue -148713866

AWSでWindowsボックスをビルドしていて、ebsボリューム「delete_on_termination」をfalseに設定しているので、ビルドが失敗した後、[a]ボリュームをアタッチし、[b]インスタンスを起動し、[c]ログを確認し、[d]インスタンスをシャットダウンし、[e]ボリュームをデタッチし、[f]手動でボリュームを削除します。

c:\windows\temp<guid>.outファイルには、実行しているPowerShellプロビジョナーのコンソール出力が含まれていることに気付きました。

この出力を取得することが、この情報を取得するためにこれらすべての追加手順を実行する必要がある唯一の理由です。

PackerがPACKER_CONSOLE_LOGS_COPY=$env:tempようなものをサポートしていて、それらのログ（特に最後に失敗したログ）を常に戻すことができ、余分な手順を回避できれば素晴らしいと思います。

最新のpackerdevリリースをコンパイルすると同時に、packerビルドの最初の失敗で一時停止するorivejの以前の修正を統合するという私の目標を共有する人のために、ここで私が行った手順を実行しました。

Complete "Setting up Go to work on Parker" steps 1-4 . ( see https://github.com/mitchellh/packer/blob/master/CONTRIBUTING.md )
git checkout master
git remote add fork https://github.com/orivej/packer
git fetch fork
git checkout -b debug-on-error fork/debug-on-error
git merge debug-on-error
make
run ./bin/packer build -debug template.json

これが機能し、エラーが発生した場合にのみプロビジョニングが一時停止したことを確認できます。

https://github.com/orivej/packer/tree/debug-on-error-2を正常にマージできませんでした

私は興味があります。私はpackerとgit、そしてこの問題にかなり慣れていません。 人々がorivejの修正を実装している他の方法はありますか？ 私は非常に明白な何かを見逃しているかもしれないので、その場合は私に手がかりを与えてください。

この問題の状態を確認するだけです。

@orivejの変更によりこの問題が解決され、プルリクエストを行う必要があるということですか？ それとも、これに対処する必要がありますか？

+1

これは本当に便利です。現在、VMを存続させるためにsleep 1800インラインシェルを使用しています。
できるだけ早く実装してください:)

Imho -debugは、私たち全員が必要としていることを行っています。 すべてのコマンドの後、次のコマンドに進むにはEnterキーを押す必要があります。 入力なし= vm alive :)

@ noose-座ってビルドを監視しません-非常に長時間実行されるセクション（SQLサーバーのインストールなど）がいくつかあり、ユーザー入力のためにそれを保持したくありません。 テストビルドを開始したいと思います。テストビルドに戻ったら、最小限の労力でデバッグできるものを用意します。

私見-デバッグはまったく役に立たない。 私は複雑なビルドを実行していますが、問題が発生するまで、Enterキーを何千回も押す忍耐力がありません。
このような簡単な機能を実装するのが非常に難しい理由は、私にはよくわかりません。

@ henris42この文脈での-debugの無用さについては同意しますが、それがそれほど簡単に思える場合は、プルリクエストを試してみませんか？

@ noose 、Jenkinsジョブ（Gitからconfig / scriptsとAnsibleプレイブックを
これはDevOpsの世界では一般的なシナリオだと思います:)

誰もがこれを必要としているようです。 これらのAMIの構築はエラーが発生しやすく、この機能によりトラブルシューティングにかかる​​時間が短縮されます。

@worstadminに同意します。 Vagrantボックスを構築する場合、さまざまな角度から問題に取り組むことができます（たとえば、仮想マシンを維持したり、nullプロビジョナーで試してみたりするなど）が、Amazonイメージは特殊な種類であり、デバッグが非常に面倒です。問題。

https://github.com/mitchellh/packer/issues/1687と組み合わせると、これは素晴らしいことです。

さらに、特にイメージの開発の初期段階などでは、プロビジョナーからのエラーを無視して続行すると役立つことがよくあります。

ほぼ3年後...そしてまだほとんど何もありません。 過去数日間、キーボードで頭をぶつけて複雑なWindowsビルドを実行しようとしましたが、出力のないPowerShellスクリプトの実行が任意にランダムに失敗し、自動クリーンアップのためにインスタンスにジャンプできません。 -debugを有効にして実行すると、手動入力を要求することによって導入された余分な「一時停止」により、この問題は発生しないようです。 これをシミュレートするために、PowerShellスクリプトに大量のスリープを追加するだけで、それは理にかなっていると思いますが、それは役に立ちません。

嘘をついていないのに、誰かが真剣に-no-destroy-on-error機能をできるだけ早く作成し、このためのPRでボールを転がすことができれば、私は誰かに100ドルの報奨金を支払います。 私（そして他の何百人ものようです）は、特にパッカーが通常自動化を念頭に置いて（CI / CDなどを介して）使用されることを考えると、この機能が必要です。 これが私の長い+1と嘆願です。

シェルプロビジョナーの回避策があるかもしれませんが、他のプロビジョナーについてはわかりません。 ：crying_cat_face：

今日はほとんど機能していましたが、Goを学んで、実装を見つけるためにいくつかのファイルを介してインターフェイスを追跡し、メタプログラミングの地獄に再び着陸することを知りませんでした:(

すでに私に似合う＃3885で私の現在の提案をチェックしてください！

@tmartinx ：

Ansibleで実行しようとしていますが、機能せず、エラー後にKVMゲストがなくなったため、そこに移動して何が問題なのかを確認することはできません...

＃3885を含む新しいパッカーリリースが出るまでの回避策として：

    {
      "type": "shell",
      "inline": [
...
        "ansible-playbook ... || (echo \"*** FAILED WITH CODE $? *** Hit Ctrl-C to terminate\"; sleep 14400; exit 1)"
        ]
    }

その後、4時間以内に、まだ実行中のVMにSSHで接続し、いろいろと調べます。

ここで何が起こっているのですか？

• Packerは、VMwareの「不明なエラー」を検出しました。
• _Packer_は、VMWareのログファイルで詳細を確認するように指示しました。 ログは出力ディレクトリにあるはずです。
• しかし、_Packer自体_が出力ディレクトリを削除するため、ログを確認できません。 ハハ！ いいね、パッカー、あなたはあなたを怒らせます！
• 他の人々のたわごとは、明らかにそうなるように、同様の状況に遭遇しました。
• 人々は、この問題に対する一見非常に単純で簡単な修正を_何年もの間_要求し続けてきました。
• それらのいくつかは、これを自分で修正しようとさえ決心しました。 それらのパッチはHashiCorpによって拒否されたか、あるいは単に失敗したようです。
• いずれにせよ、HashiCorpは無線封止を維持しています。 彼らはこれを修正するつもりはないようです。

米国政府がHashiCorpをギャグ命令し、これを修正しないように指示したと結論付けるのでしょうか。

私は別の説明を思い付くのに苦労しています。

HashiCorpのツールはDevOpsy全体に適しているという印象を持っていましたが、今は考え直しています。 真剣に。 私たちは皆、ここで明らかな何かを見逃していますか、それともHashiCorpは非常に日陰になっていますか？

このチケットがクローズされる理由は、問題がすでに修正されているためです。

コマンドラインにフラグ-on-error=askを追加すると、エラーが発生した場合に、ビルドアーティファクトを削除するかどうかを確認するメッセージが表示されます。

さらに、この質問に答える前に、VMにSSH接続していろいろと調べることができます。

@ peterlindstrom234 、これはすでに実装されています。 「-on-error = abort」を使用できます。エラーが発生した場合、packerはクリーンアップを実行しないでください。

申し分なく、私の悪い。 でも不思議なことに時間がかかりました。

@ peterlindstrom234米国政府の箝口令のため、時間がかかりました