Packer: --no-destroy-on-error, как Vagrant

Звучит разумно. Я думаю, что флаг -debug действительно правильный подход, но, возможно, флаг -debug должен разрешать такие параметры, как:

• Шаг через каждый шаг
• Продолжайте до ошибки
• Продолжайте, пока не начнутся этапы очистки

Я бы нашел вариант продолжить до ошибки и не уничтожать виртуальную машину чрезвычайно полезным

Если кто-то может дать мне несколько указаний о том, с чего начать поиски реализации этого, я могу потратить некоторое время на добавление этого в качестве опции.

Мне это тоже было бы очень полезно.

@timmow вам может потребоваться изменить каждый шаг очистки создания экземпляра сборщика, чтобы ничего не делать, если установлен определенный флаг (например, https://github.com/mitchellh/packer/blob/master/builder/amazon/common/step_run_source_instance.go # L122)

Потребуется определенная работа, чтобы прочесать все этапы и выяснить, где было бы целесообразно не предпринимать никаких действий.

Идея, которую я только что пришла, заключалась в том, чтобы дать флаг, который будет ждать ввода пользователя перед обработкой любого шага очистки. Таким образом, вы можете выполнить отладку, например, нажать Enter, а упаковщик позаботится об очистке.

Не стесняйтесь связаться со мной здесь, если я могу предложить какую-либо помощь.

fyi, это сделано в режиме FILO здесь https://github.com/mitchellh/multistep/blob/master/basic_runner.go#L71

вам может потребоваться расширить базовый бегун (debuggable_runner?)

Было бы здорово добавить что-то вроде функции «пропуска» шагов ниже, которая в основном пропускала бы шаги очистки для этой конфигурации типа --no-destroy-on-error . Это также позволило бы включить некоторые интересные вещи в режиме -debug , например, интерактивное нажатие s для пропуска.

Подобно «приостановке» отладки, я думаю, что вариант вроде -pause-on-error был бы полезен.

Привет, я вижу, что эта проблема устранена этим коммитом https://github.com/mitchellh/packer/commit/2ed7c3f65cc2e0a14d39d8934ef1168f8192bb08, но я не вижу изменения в HEAD основной ветки. Куда и почему исчезло?

Мне это тоже очень нужно.

Есть ли надежда на эту функцию? Что нужно сделать для слияния 2ed7c3f или его разновидности?

Да, я тоже мог бы использовать эту опцию. Я вижу, это было совершено, но затем исчезло.

Есть ли обновления по этому поводу?

Мне бы это тоже очень понравилось. Я не могу сказать вам, сколько времени я потратил на отладку проблем и мне пришлось пройти долгий процесс создания виртуальной машины, чтобы снова и снова возвращаться к ошибке. Возможность сохранить виртуальную машину была бы огромной победой.

Есть ли ETA, когда эта (или подобная функция) будет объединена с основной? Пытаюсь использовать Packer для создания виртуальной машины с Visual Studio, установленной как часть базового блока Vagrant, и мне действительно нужно, чтобы он не уничтожил виртуальную машину, прежде чем у меня будет возможность посмотреть, почему шаги не работают. Подтверждение каждого шага с помощью --debug недопустимо.

Еще одно голосование за это, так как опция -debug подавляет ошибку, которую я пытаюсь проанализировать.

Потрачено столько времени на отладку конечного состояния машины до того, как она выйдет из строя. Переключатель -debug не сокращает его - я хочу, чтобы он выполнялся в обычном режиме, а затем оставил рабочую папку в такт после сбоя, чтобы я мог диагностировать с помощью журналов и состояния. Очень жду какого-то переключателя рабочего состояния.

Еще +1 за эту функцию, это было бы очень полезно.

+1 Возникли аналогичные проблемы, когда было бы неплохо отладить конечное состояние, настроить некоторые сценарии подготовки, а затем снова запустить сборку, чтобы увидеть, исправил ли это процесс, вместо того, чтобы вручную нажимать Enter на любом этапе отладки.

Еще один +1 за эту функцию. Было бы неплохо узнать, что с этим случилось? Никто из команды не ответил. Идите вперед, ступайте к тарелке, это не повредит. СМЕШНО! Я совершенно не знаком с Пакером. Я был в конце сборки ISO за 1,5 часа, и это произошло. Тестирование и отладка должны иметь первостепенное значение для создания полного потока приложений.

+1 и здесь мы создаем наши изображения без заголовка, поэтому наличие --debug require ручное пошаговое выполнение для нас бесполезно, но возможность проверить ошибочное изображение было бы здорово.

: +1: Мне тоже нравится эта функция

+1 Это было бы здорово!

Относится к # 1687 или, возможно, дублируется

+1 Было бы очень полезно иметь возможность оставить виртуальную какая она есть, не удаляя

+1 этот будет очень полезен

+1, чтобы помочь отладить подготовку при сбое только с Packer

+1 Я в одной лодке. Я потратил неисчислимые часы на воссоздание виртуальных машин Windows, только чтобы получить ошибку Chef на этапе подготовки и не было возможности отладить виртуальную машину, когда она была удалена. Только пусть будет возможность не удалять все во время сбоя.

Увидев, что эта проблема существует уже два года, я не надеюсь, что она будет исправлена. Мне действительно нравится Packer, но в итоге я трачу больше времени на ожидание этапа сборки, чем на использование результатов.

Pleeeeeaseeeeeee +1

+1

+1

+1

Интересно, какой аргумент для этого, нашел эту проблему через Google. Было грустно, когда фича не существовало.

Привет, разработчики, я еще раз посетил эту ветку и с уверенностью могу сказать, что, хотя мне удалось продолжить эффективное использование упаковщика, эта ошибка серьезно замедляет разработку наших систем. Мы справимся, но было бы искренне хорошо, если бы сотрудник мог дать некоторые рекомендации по этому вопросу @mitchellh. У меня даже может быть время внести свой вклад в решение, если мне удастся указать правильное направление, но я буду ждать вашего ответа или кого-нибудь из вашей команды, надеюсь. Спасибо за прекрасный инструмент. Я определенно хочу, чтобы вы и ваша команда знали, насколько я считаю этот продукт крутым.

Так как мне надоели все уведомления +1 по электронной почте для функции, которую я тоже хотел ;-), я начал копаться в кодовой базе и добавил начальную реализацию. ПРИМЕЧАНИЕ - это еще не проверено ... и я даже не знаю, будет ли это работать должным образом. Если вы попытаетесь собрать его из исходников, я столкнулся с интересной проблемой, когда Packer сам ссылался на себя из github, что привело к неправильной сборке этого кода. Вам нужно будет временно связать исходную папку вашего упаковщика в GoPath с папкой, в которую вы загружаете это репо (или подождите, пока я протестирую и отправлю запрос на перенос).

https://github.com/jcoutch/packer

Тот факт, что это не поведение по умолчанию, простите меня за французский, чертовски безумен. Сделали опечатку в сценарии установки? Что ж, давай просто удобно _ уничтожим всю твою работу и никогда не вернем тебе тот час твоей жизни. Над. И более. Очередной раз._

Я полагаю, что буквально каждый человек, использующий этот инструмент для чего-либо, помимо простейших примеров, сталкивается с этой проблемой каждый раз, когда они его используют. Очевидно, что эта функция пользуется огромным спросом, но 2 года спустя она все еще не реализована.

Совершенно потрясающе.

+1

Боже, это был язвительный комментарий. Вчера плохое настроение, но все это время напрасно тратит много времени и денег.

@jcoutch - у вас есть сборка, которой вы можете поделиться?

У меня есть сборка OSX на моей машине, просто не было возможности проверить,
пока работает. Работаю над этим в свободное время ... чего у меня не было особо
пощадить в последнее время. Не говоря уже о том, что это мой первый опыт работы с Go (довольно
интересный язык.) Попробую опробовать до конца этой недели,
и если все будет хорошо, я отправлю запрос на перенос. Я также постараюсь
публиковать сборки OSX и Windows для тестирования другими, как только я узнаю, что они стабильны.

В среду, 23 сентября 2015 г., 17:14 Рич Джонс [email protected] написал:

Боже, это был язвительный комментарий. Вчера плохое настроение, а все это время
напрасная трата времени и денег.

@jcouth - у вас есть сборка, которой вы можете поделиться?

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/mitchellh/packer/issues/409#issuecomment -142730452.

Pleeeease !! :-D

Я пытаюсь запустить его с помощью Ansible, но он не работает, и гость KVM ушел после ошибки, поэтому невозможно перейти туда, чтобы узнать, что не так ...

Ура!

Многое нужно. Благодарю.

Вот патч @jcoutch с правильными окончаниями строк для облегчения просмотра: https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

Этот патч предотвращает удаление только в случае сбоя препроцессоров, он не сохраняет артефакты при сбое построителя (с его инициаторами).

РЕДАКТИРОВАТЬ: Это похоже на намерение, но на самом деле он ничего не делает, хотя его можно легко исправить, чтобы удовлетворить его.

Да, у меня не было возможности ответить в этой беседе. Я наконец попробовал
из моих изменений с падающим поставщиком ... это не работает, как я
предназначена. Если посмотреть глубже в код, похоже, что построитель обрабатывает
удаление артефактов при сбое инициализации ... вместо кода I
изменен.

В сб, 3 октября 2015 г., 9:37 Ориведж Деш [email protected] написал:

Вот патч @jcoutch https://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 - это доказательство концепции, которая переопределяет --debug чтобы остановить его только один раз после первого сбоя. Это требует https://github.com/mitchellh/multistep/pull/5 для остановки перед первой очисткой, а не перед второй очисткой. Такое поведение было предложено в # 1687. (Это не доказательство концепции, а решение, если переопределение --debug как предложено в # 1687, в порядке.)

+1 к сохранению артефактов при неудачной сборке в режиме -debug.

Я какое-то время использую упаковщик с патчем, и у меня никогда не было причин запускать его без -debug . Интересно, стоит ли мне публиковать двоичные файлы для более широкого тестирования.

+1

Я только что заметил, что опубликованная мною ссылка была патчем для мультишага, а не для упаковщика. Исправление, которое заставляет упаковщик приостанавливать работу при ошибке при работе с -debug находится по адресу https://github.com/orivej/packer/tree/debug-on-error.

@orivej с какого патча мне начать, если я хочу протестировать ваш патч без разрушения? https://github.com/orivej/packer/commit/a713a4698831a8dfcd48484dc4675631779b6840 ?

Да, есть один коммит, orivej @ a713a46. Его все еще можно аккуратно переустановить на мастер.
Вам также понадобится патч для github.com/mitchellh/multistep с https://github.com/mitchellh/multistep/pull/5 , иначе упаковщик остановится после уничтожения последнего шага.

@orivej у вас есть исправленный двоичный файл для OSX? Перезапуск всего процесса сборки из-за небольшой ошибки при сборке Gentoo Linux невероятно болезнен (отнимает много времени). Для меня просто необходимо иметь возможность загрузить ящик после сбоя и выяснить, что не так.

Я добавил возможность повторить неудачный шаг вместо прерывания, хотя даже если это удастся, сборка в целом может потерпеть неудачу; и, если я не ошибся, упаковщик не может надежно обрабатывать ввод, и пользователю, возможно, придется отвечать несколько раз.

Это изменение не зависит от пропатченного мультишага и живет в ветке , коммит .

Я загрузил двоичные файлы сюда: https://orivej-packer.s3.amazonaws.com/index.html (поддерево debug-on-error-2 ).

Для меня просто необходимо иметь возможность загрузить ящик после сбоя и выяснить, что не так.

Мой патч не сохраняет поле, которое может быть загружено, но вместо этого он оставляет текущий ящик активным до тех пор, пока вы вручную не завершите сборку, чтобы вы могли подключиться к нему по SSH и выполнить отладку (при вызове packer с -debug вариант).

Спасибо за отзыв, @orivej.

Мой патч не сохраняет ящик, который может быть загружен, но вместо этого он оставляет текущий ящик активным до тех пор, пока вы вручную не завершите сборку, чтобы вы могли подключиться к нему по SSH и выполнить отладку (при вызове упаковщика с параметром -debug).

Заметил, что сборка упаковщика по умолчанию с --debug приостанавливается до того, как среда будет уничтожена, что дает вам возможность отладить ее, как вы описали. Для этого я использую "headless": false . Насколько отличается процесс с вашим патчем?

• Он заставляет упаковщик приостанавливаться только после сбоя шага, вместо того, чтобы останавливаться после каждого шага.
• Он приостанавливается перед очисткой пакера после неудачной операции. (Хотя я не помню, зачем мне это было нужно, поскольку самый проблемный этап подготовки не выполняет никакой очистки.)
• Вторая редакция патча позволяет повторить неудачный шаг. (В случае сбоя инициализации все инициаторы перезапускаются.)

Я только что заметил, что в # 2608 было принято неудачное решение отдать приоритет плагинам от старой версии упаковщика к новым встроенным модулям, поэтому для использования моей сборки упаковщика (или будущих выпусков упаковщика, если авторы не пересмотрят это поведение), вам нужно удалить все двоичные файлы, имена которых начинаются с packer- .

Ненадежная обработка ввода также является артефактом # 2608, я посмотрю, смогу ли я это исправить.

Ненадежная обработка ввода вызвана дополнительной инициализацией встроенных плагинов, в частности setupStdin() в main.go . Поскольку этот вызов, похоже, в любом случае не может служить заявленной цели, я смог отключить его без каких-либо последствий и перестроил свои двоичные файлы.

Было бы очень полезно просто выйти из упаковщика без остановки или уничтожения виртуальной машины в случае ошибки. Это особенно важно в компонентах подготовки, которые обычно содержат наиболее настраиваемую логику. Возможность подключиться по SSH к компьютеру и повторно запустить исходный сценарий или попробовать модифицированный сценарий или рецепт для тестирования может дать быстрое и ценное представление о том, что на самом деле вызвало ошибку и что это за исправление. Создание всей сборки упаковщика занимает слишком много времени, чтобы требовать его даже для самого простого устранения неполадок.

Флаг -debug полезен, но он упрощает процесс вручную. Очень часто бывает полезно запустить автоматическую сборку, но чтобы она завершилась при обнаружении ошибки и оставила систему в состоянии, позволяющем исследовать причину и исправить.

: +1: независимо от того, проходит ли -debug или не проходит, должна быть возможность оставить экземпляр работающим, чтобы вы могли воспроизводить сценарии / отлаживать экземпляр и т. Д. Если это каким-то образом не мешает захвату образа AMI.

+1

+1 .. Я удивлен, что это будет примерно через 2,5 года, так как это будет так полезно. Это значительно упростило бы мою жизнь по устранению неполадок в моей сборке Packer.

Я смог преодолеть это на AWS, используя защиту от прерывания на экземпляре до запуска chef-client. это не достойный вариант, но он работает. Любые другие варианты :)

+500 - почему этой функции еще нет?

Может быть, мы, как разработчики, могли бы попробовать запачкать руки вместо того, чтобы жаловаться?

Запрос функции не может быть проще.

• Прочтите новый параметр командной строки ( --no-destroy-on-error )
• Добавьте скромный if в нужное место. Псевдокод:

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

Я попробую. И если это сработает, я не буду им делиться (в основном, чтобы избежать гипотетических запросов / жалоб). Усилия - это хорошо.

@vemv , я уже решил эту проблему двумя коммитами на https://github.com/orivej/packer/commit/debug-on-error-2.

@orivej Это --pause-on-error который, на мой взгляд, является лучшим способом (если на каком-то этапе не удается выполнить операцию, дождитесь нажатия клавиши перед очисткой, что позволит пользователю войти в систему и устранить неполадки).

Не могли бы вы открыть PR со своим кодом, и мы обсудим детали там.
CC @cbednarski

@vemv Я

@orivej и @ rickard-von-essen, все, что требует ввода данных пользователем, на самом деле не работает для меня, поскольку я использую Packer только в автоматизированных инструментах (например, Jenkins или TravisCI); Я знаю, что на моем месте много других людей. Я думаю, что мне действительно нужно что-то, что (1), возможно, увеличивает многословность вывода, и (2) просто оставляет исходную машину (будь то EC2, VMWare, что угодно) работающей, чтобы человек мог ее проверить после работа не удалась.

В настоящее время отладка будет приостанавливаться между шагами, требуя, чтобы вы нажали Enter, чтобы продолжить, поэтому, пока вы знаете, на каком этапе вы собираетесь потерпеть неудачу, вы можете просто «удерживать» виртуальную машину там для целей отладки, но, очевидно, это не так хорошо. Вы действительно хотите, чтобы шаблон проходил каждый шаг, чтобы вы могли проверить полное состояние ошибки.

Просто добавляю мой: +1 :. Я действительно мог бы использовать эту функцию.

@jantman Я собираюсь сделать так, чтобы packer -debug пропустил очистку, когда процесс завершился ошибкой и не может получить ввод (например, при вводе из /dev/null ). Обратите внимание, что последовательность запуска упаковщика построена на идее, что каждый шаг может и будет очищен впоследствии, поэтому резкое завершение работы оставит систему в состоянии, с которым упаковщик не сможет справиться самостоятельно (например, он будет жаловаться, что выходной каталог уже существует), поэтому вам следует ожидать, что вам придется выяснить, как сделать ваш процесс повторяемым, но это, вероятно, легко.

@ rickard-von-essen Я обновлю свой патч (добавлю новых провайдеров) и сделаю запрос на перенос позже сегодня.

Из @DarwinJS в https://github.com/mitchellh/packer/issues/3445#issue -148713866

Я создаю окна Windows на AWS, и для тома ebs «delete_on_termination» установлено значение false, поэтому после неудачной сборки я могу [a] подключить том, [b] загрузить экземпляр, [c] посмотреть его журналы, [d] выключить экземпляр, [e] отсоединить том, [f] вручную удалить том.

Я заметил, что файлы c:\windows\temp<guid>.out содержат консольный вывод запускаемых мной программ подготовки PowerShell.

Получение этого вывода - единственная причина, по которой мне нужно предпринять все эти дополнительные шаги, чтобы получить эту информацию.

Было бы здорово, если бы Packer поддерживал что-то вроде PACKER_CONSOLE_LOGS_COPY=$env:temp чтобы эти журналы всегда можно было вернуть (особенно последний отказавший), и я мог бы избежать дополнительных шагов.

Для тех, кто разделяет мою цель скомпилировать последнюю версию packer dev, а также интегрировать более раннее исправление 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, чем я описал? Возможно, мне не хватает чего-то очень очевидного, поэтому, пожалуйста, сообщите мне, если это так.

Просто проверяю состояние этой проблемы.

Может быть , изменения перенос ? Или это еще нужно решать?

+1

это было бы действительно полезно, прямо сейчас я использую встроенную оболочку с sleep 1800 чтобы поддерживать виртуальную машину в живых.
Пожалуйста, внедрите как можно скорее :)

Имхо -debug делает то, что нам всем нужно. После каждой команды вам нужно нажимать клавишу ВВОД, чтобы перейти к следующей. Нет входа = vm жив :)

@noose - я не сижу и не смотрю сборку - есть некоторые очень длинные разделы (например, установка SQL-сервера), которые я бы не хотел, чтобы он задерживался для ввода пользователем. Я хотел бы начать тестовую сборку, и когда я вернусь к ней, у меня будет что-то, что я могу отладить с минимальными усилиями.

IMHO -debug совершенно бесполезен. Я запускаю сложные сборки, и у меня действительно нет терпения нажимать клавишу ВВОД тысячу раз, пока я не доберусь до проблемы.
Я действительно не понимаю, почему такую ​​простую функцию так сложно реализовать.

@ henris42, хотя я согласен с вами в бесполезности -debug в этом контексте, если это кажется таким простым делом , почему бы вам не попробовать выполнить pull request?

@noose , я автоматизирую сборку упаковщика в задании Jenkins (которое извлекает из Git config / scripts и Ansible playbooks). При таком использовании упаковщика интерактивный режим бесполезен; гораздо полезнее анализ после сбоя.
Думаю, это распространенный сценарий в мире DevOps :)

Вроде всем это нужно. Создание этих AMI подвержено ошибкам, и эта функция позволит сократить время на устранение неполадок.

Я согласен с @worstadmin. В случае создания боксов Vagrant вы можете решать проблему с разных сторон (например, держать виртуальную машину, пробовать что-то с нулевым инициатором и т. проблема.

В сочетании с https://github.com/mitchellh/packer/issues/1687 это было бы здорово.

Кроме того, часто бывает полезно игнорировать ошибки провайдеров и позволить этому продолжаться, особенно на ранней стадии разработки образа и т. Д.

Почти 3 года спустя ... и все еще почти ничего. Я провел последние несколько дней, ломая голову о клавиатуре, пытаясь создать сложные сборки Windows, которые произвольно и случайным образом завершают выполнение сценариев PowerShell без вывода, и из-за автоматической очистки я не могу перейти на экземпляр. Когда я запускаю с включенной -debug, дополнительные «паузы», вызванные требованием ручного ввода, по-видимому, не вызывают этой проблемы. Что, как вы могли подумать, имеет смысл. Я просто добавляю тонну сна в свои сценарии PowerShell, чтобы смоделировать это, и это не помогает.

Даже не вру, я дам кому-нибудь Paypal вознаграждение в размере 100 долларов, если кто-то сможет как можно скорее серьезно сделать функцию --no-destroy-on-error и запустить PR для этого. Мне (и, кажется, сотням других) эта функция нужна, особенно если учесть, что упаковщик обычно используется с автоматизацией (через CI / CD и т. Д.). Итак, вот мой длинный +1 и просьба.

Привет, может быть обходной путь для

Сегодня он почти работал, но изучая 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 часа, чтобы подключиться по ssh к все еще работающей виртуальной машине и покопаться.

Что, черт возьми, здесь происходит?

• Packer обнаружил "Неизвестную ошибку" VMware.
• _Packer_ сказал мне проверить файл журнала VMWare для получения дополнительной информации. Предполагается, что журнал находится в выходном каталоге.
• Но сам _Packer_ удаляет выходной каталог, поэтому я не могу проверить журнал. Ха-ха! Молодец, Пакер, ты негодяй!
• Множество других людей столкнулись с подобной ситуацией, что и должно было случиться.
• Люди продолжали просить, казалось бы, очень простое решение этой проблемы _ в течение многих_ лет.
• Некоторые из них даже решили попробовать исправить это сами. Похоже, их патчи были отклонены HashiCorp, или, может быть, они были просто неудачными.
• В любом случае HashiCorp хранит радиомолчание. Похоже, они просто никогда этого не исправят.

Должны ли мы сделать вывод, что правительство США заткнило HashiCorp и сказало им не исправлять это или что-то в этом роде?

Мне трудно придумать альтернативные объяснения.

У меня сложилось впечатление, что инструменты HashiCorp - хороший выбор для всего DevOpsy, но теперь у меня возникли сомнения. Шутки в сторону. Мы все упускаем здесь что-то очевидное, или HashiCorp просто очень сомнительна?

Эта заявка закрыта потому, что проблема уже устранена.

Добавьте флаг -on-error=ask в командную строку, а затем, если возникнет ошибка, вам будет предложено удалить артефакты сборки или нет.

Кроме того, прежде чем ответить на этот вопрос, вы можете ssh войти в виртуальную машину и покопаться.

@ peterlindstrom234 , это уже реализовано. Вы можете использовать "-on-error = abort", и упаковщик не должен выполнять очистку при возникновении ошибки.

Хорошо, плохо. Хотя это действительно заняло странно много времени.

@ peterlindstrom234 это заняло много времени из-за