Packer: --no-destruir-por-error como Vagrant

Suena razonable. Creo que la bandera -debug es de hecho el enfoque correcto aquí, pero tal vez la bandera -debug debería permitir opciones como:

• Paso por cada paso
• Continuar hasta un error
• Continuar hasta que comiencen los pasos de limpieza

Encontraría la opción de continuar hasta un error y no destruir la máquina virtual extremadamente útil

Si alguien me puede dar algunos consejos sobre dónde comenzar a buscar para implementar esto, es posible que pueda dedicar algo de tiempo a agregar esto como una opción

Esto también sería muy útil para mí.

@timmow, es posible que deba modificar el paso de limpieza de creación de instancias de cada constructor para no hacer nada si se establece una determinada

Sería una cierta cantidad de trabajo revisar todos los pasos y averiguar dónde sería apropiado no tomar ninguna medida.

Una idea que acabo de tener sería dar una bandera que esperaría la entrada del usuario antes de procesar cualquier paso de limpieza. De esa manera, podría realizar su depuración, presionar enter, por ejemplo, y el empacador se encargaría de la limpieza.

No dude en enviarme un ping aquí si puedo ofrecer ayuda.

para su información, se hace de la manera FILO aquí https://github.com/mitchellh/multistep/blob/master/basic_runner.go#L71

es posible que deba extender el corredor básico (debuggable_runner?)

Sería genial agregar algún tipo de funcionalidad de "omisión" de pasos más abajo, que básicamente omitiría pasos de limpieza para esta configuración de tipo --no-destroy-on-error . También habilitaría algunas cosas interesantes en el modo -debug , como presionar s para omitir, de forma interactiva.

Similar a la depuración "pausar", creo que una opción como -pause-on-error sería beneficiosa.

Hola, veo que este problema se soluciona con este compromiso https://github.com/mitchellh/packer/commit/2ed7c3f65cc2e0a14d39d8934ef1168f8192bb08 pero no veo el cambio en HEAD de la rama maestra. ¿Dónde y por qué desapareció?

Realmente necesito esto también.

¿Hay alguna esperanza de tener esta función? ¿Qué se debe hacer para fusionar 2ed7c3f o alguna variación?

Sí, también podría usar esta opción. Veo que se cometió pero luego desapareció.

¿Hay alguna actualización sobre esto?

Realmente me encantaría esto también. No puedo decirle cuánto tiempo he perdido tratando de depurar problemas y tengo que pasar por un largo proceso de creación de VM para llegar al error una y otra vez. Ser capaz de mantener la VM alrededor sería una gran victoria.

¿Hay una ETA cuando esta (o una funcionalidad similar) se fusionará con la principal? Intento usar Packer para construir una VM con Visual Studio instalado como parte de la caja Vagrant base, y realmente lo necesito para no destruir la VM antes de tener la oportunidad de ver por qué fallan los pasos. Tener que reconocer cada paso a través de --debug no es aceptable.

Otro voto para este, ya que la opción -debug suprime la falla que estoy tratando de analizar.

Pasando tanto tiempo intentando depurar el estado final de la máquina antes de que falle. El interruptor -debug no lo corta; quiero que se ejecute a través del proceso normal y luego deje la carpeta de trabajo intacta después de la falla para poder diagnosticar con registros y estado. Realmente espero con ansias algún tipo de interruptor de estado de trabajo de conservación.

Otro +1 para esta función, sería inmensamente útil.

+1 Encontrarse con problemas similares en los que sería bueno depurar el estado final, modificar algunos scripts de aprovisionamiento y luego ejecutar la compilación nuevamente para ver si eso solucionó el proceso, en lugar de presionar manualmente enter en cada paso de depuración.

Otro +1 para esta función. ¿Sería bueno saber qué pasó con esto? Nadie del equipo respondió. Adelante, sube al plato, no duele. Jajaja Soy totalmente nuevo en Packer. Estaba al final de una compilación ISO de 1,5 horas y sucedió esto. Las pruebas y la depuración deberían ser primordiales para llevar una aplicación totalmente dulce a todo el flujo.

+1 aquí también, creamos nuestras imágenes sin cabeza, por lo que tener --debug requiere un paso manual no es bueno para nosotros, pero poder inspeccionar la imagen defectuosa sería genial.

: +1: También me gusta tener esta función

+1 ¡Esta función sería genial!

Relacionado o tal vez duplicado por # 1687

+1 Solo para poder dejar la VM como está sin eliminar @error sería muy útil. Nuestros scripts de instalación son bastante largos, muchos, muchos pasos con el sistema actual .. :(

+1 este te será muy útil

+1 para ayudar a depurar el aprovisionamiento cuando falla solo con Packer

+1 Estoy en el mismo barco. He pasado incontables horas recreando máquinas virtuales de Windows, solo para tener un error de Chef en el paso de aprovisionamiento y no hay forma de depurar la máquina virtual cuando se elimina. Solo permita que haya una opción para no eliminar todo durante una falla.

Después de ver que este problema ha estado vivo durante dos años, no tengo ninguna esperanza de que se solucione. Realmente estoy tratando de que me guste Packer, pero termino pasando más tiempo esperando el paso de compilación que usando los resultados.

Pleeeeeaseeeeeee +1

+1

+1

+1

Se preguntó cuál era el argumento para esto, encontré este problema a través de Google. Me entristeció cuando la función no existía.

Hola desarrolladores, volví a visitar este hilo y es seguro decir que, aunque me las arreglé para seguir usando Packer de manera efectiva, este error ralentiza seriamente el desarrollo de nuestros sistemas. Podemos arreglárnoslas, pero sinceramente sería bueno si un miembro del personal pudiera brindar alguna orientación sobre este tema @mitchellh. Es posible que incluso tenga tiempo para aportar una solución si se me puede señalar en la dirección correcta, pero espero su respuesta o la de alguien de su equipo. Sin embargo, gracias por la increíble herramienta. Definitivamente quiero que usted y su equipo sepan lo increíble que creo que es este producto.

Como me cansé de todas las notificaciones por correo electrónico +1 para una función que también quería ;-), comencé a investigar en el código base y agregué una implementación inicial. NOTA: esto aún no se ha probado ... y ni siquiera sé si funcionará correctamente. Si intenta compilarlo desde la fuente, me encontré con un problema interesante con Packer que se auto-referencia a sí mismo desde github, lo que hará que este código no se compile correctamente. Deberá vincular temporalmente su carpeta de origen del empaquetador en GoPath a la carpeta en la que descargó este repositorio (o esperar a que pruebe y envíe una solicitud de extracción).

https://github.com/jcoutch/packer

El hecho de que este no sea el comportamiento predeterminado, si me disculpas en francés, es una locura. ¿Cometió un error tipográfico en su script de instalación? Bueno, vamos a _destruir convenientemente todo su trabajo y nunca devolverle esa hora de su vida. Encima. Y más. Otra vez._

Me imagino que _literalmente cada persona_ que usa esta herramienta para cualquier cosa más allá de los ejemplos más simples se encuentra con este problema _ cada vez que la usa_. Claramente, existe una demanda masiva de esta función y, sin embargo, todavía no se implementa, 2 años después.

Absolutamente asombroso.

+1

Hombre, ese fue un comentario sarcástico. Ayer estuvo de mal humor, pero todo este tiempo perdido empieza a costar mucho tiempo y dinero.

@jcoutch : ¿tienes una compilación que puedas compartir?

Tengo una compilación OSX en mi máquina, pero no he tenido la oportunidad de probar si
funciona todavía. Trabajando en esto en mi tiempo libre ... que no he tenido mucho que
sobra últimamente. Sin mencionar que esta es mi primera experiencia con Go (bastante
un idioma interesante). Intentaré probarlo a finales de esta semana,
y si todo se ve bien, enviaré una solicitud de extracción. También intentaré
publicar compilaciones de OSX y Windows para que otros las prueben una vez que sepa que es estable.

El miércoles 23 de septiembre de 2015 a las 5:14 p.m., Rich Jones [email protected] escribió:

Hombre, ese fue un comentario sarcástico. Ayer de mal humor, pero todo este tiempo
perder está empezando a costar mucho tiempo y dinero.

@jcouth - ¿tienes una compilación que puedas compartir?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/mitchellh/packer/issues/409#issuecomment -142730452.

¡¡Por favor !! :-RE

Estoy tratando de ejecutarlo con Ansible, pero no funciona y el invitado KVM se ha ido después del error, por lo que no es posible ir allí para ver qué está mal ...

¡Salud!

Muy necesario. Gracias.

Aquí está el parche @jcoutch con finales de línea adecuados para una revisión más fácil: https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

Este parche evita la eliminación solo si los preprocesadores fallan, no conserva los artefactos cuando falla un constructor (con sus aprovisionadores).

EDITAR: Esa parece ser la intención, pero en realidad no hace nada, aunque podría arreglarse fácilmente para cumplirla.

Sí, no había tenido la oportunidad de responder a este hilo. Finalmente lo intenté
mis cambios con un aprovisionador que cae ... no funciona como yo
destinado a. Mirando más profundamente en el código, parece que el constructor maneja
la eliminación de artefactos en una falla de aprovisionamiento ... en lugar del código I
modificado.

El sábado 3 de octubre de 2015 a las 9:37 a.m. Orivej Desh [email protected] escribió:

Aquí está @jcoutch https://github.com/jcoutch parche con la línea adecuada
finales para una revisión más fácil: orivej @ 23bbd4d
https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/mitchellh/packer/issues/409#issuecomment -145249481.

Aquí https://github.com/orivej/multistep/commit/e02bce9811c65138ea2e84c7162cd8769f35858f es una prueba de concepto que redefine --debug para detenerse solo una vez, después de la primera falla. Requiere que https://github.com/mitchellh/multistep/pull/5 se detenga antes de la primera limpieza en lugar de antes de la segunda. Este comportamiento fue propuesto en # 1687. (Esto no es una prueba de concepto, sino una solución si redefinir --debug como se propone en # 1687 está bien).

+1 para conservar artefactos en una compilación fallida en modo -debug.

He estado ejecutando Packer durante un tiempo con el parche y nunca tuve una razón para iniciarlo sin -debug . Me pregunto si debería publicar binarios para pruebas más amplias.

+1

Acabo de notar que el enlace que publiqué era un parche para varios pasos, no para empaquetador. La solución que hace que el empaquetador se detenga en caso de error cuando se ejecuta con -debug está en https://github.com/orivej/packer/tree/debug-on-error

@orivej ¿con qué parche debo comenzar si quiero probar su parche de comportamiento de no destrucción? https://github.com/orivej/packer/commit/a713a4698831a8dfcd48484dc4675631779b6840 ?

Sí, hay una confirmación, orivej @ a713a46. Todavía se puede rebasar limpiamente en master.
También necesita un parche por github.com/mitchellh/multistep de https://github.com/mitchellh/multistep/pull/5 , o el empacador se detendrá después de destruir el último paso.

@orivej ¿tienes un binario parcheado para OSX? Reiniciar todo el proceso de construcción debido a un pequeño error al construir una caja de Gentoo Linux es increíblemente doloroso (consume mucho tiempo). Tener la posibilidad de cargar la caja después de la falla y descubrir qué está mal es una necesidad para mí.

Agregué una opción para volver a intentar el paso fallido en lugar de abortar, aunque incluso si esto tiene éxito, la compilación en general puede fallar; y, si no me equivoqué, el empaquetador no procesa la entrada de manera confiable y el usuario puede tener que responder varias veces.

Este cambio no depende de varios pasos parcheados y vive en la rama , se confirma .

Subí los binarios aquí: https://orivej-packer.s3.amazonaws.com/index.html (subárbol debug-on-error-2 ).

Tener la posibilidad de cargar la caja después de la falla y descubrir qué está mal es una necesidad para mí.

Mi parche no conserva la caja que se puede cargar, sino que deja la caja actual viva hasta que finalice manualmente la compilación, para que pueda SSH en ella y realizar la depuración (al llamar a packer con -debug opción).

Gracias por los comentarios, @orivej.

Mi parche no conserva la caja que se puede cargar, sino que deja la caja actual viva hasta que finalice manualmente la compilación, de modo que pueda SSH en ella y realizar la depuración (al llamar al empaquetador con la opción -debug).

Noté que la compilación predeterminada del empaquetador, con --debug , se detiene antes de que el entorno se destruya, lo que le brinda la opción de depurarlo como lo describió. Para hacer eso, uso "headless": false . ¿Qué tan diferente es el proceso con su parche?

• Hace que el empacador se detenga solo después de que falla un paso, en lugar de hacer una pausa después de cada paso.
• Hace una pausa antes de que el empacador limpie después del paso fallido. (Aunque no recuerdo por qué necesitaba esto, ya que el paso de aprovisionamiento más problemático no hace ninguna limpieza).
• La segunda edición del parche permite volver a intentar el paso fallido. (Cuando el aprovisionamiento falla, esto vuelve a ejecutar todos los aprovisionadores).

Acabo de notar que # 2608 tomó una decisión desafortunada de priorizar los complementos de la versión anterior de Packer a los complementos incorporados más nuevos, por lo que para usar mi compilación de Packer (o futuras versiones de Packer, a menos que los autores reconsideren este comportamiento), debe eliminar todos binarios cuyos nombres comienzan con packer- .

El manejo de entrada no confiable también es un artefacto del # 2608, veré si puedo solucionarlo.

El manejo de entrada no confiable es causado por la inicialización adicional de complementos incorporados, en particular por setupStdin() en main.go . Dado que esta llamada parece no poder cumplir su propósito declarado de todos modos, pude deshabilitarla sin repercusiones y reconstruí mis binarios.

Sería muy útil simplemente poder salir de Packer sin detener o destruir la VM en caso de error. Esto es particularmente importante en los componentes de aprovisionamiento que generalmente contienen la lógica más personalizada. Ser capaz de SSH en un cuadro y volver a ejecutar el script original o probar un script modificado o una receta para la prueba puede proporcionar información rápida y valiosa sobre lo que realmente causó el error y cuál es la solución. Hacer una compilación completa de empaquetador requiere demasiado tiempo para requerirlo incluso para la solución de problemas más simple.

El indicador -debug es útil, pero hace que el proceso sea mucho más manual. Muy a menudo, es útil ejecutar una compilación desatendida, pero hacer que se cierre cuando encuentre un error y deje el sistema en un estado que permita investigar la causa y corregirlo.

: +1: independientemente de si -debug pasa o falla, debería haber una opción para mantener la instancia en ejecución para que pueda reproducir scripts / depurar en la instancia, etc. A menos que esto interfiera de alguna manera con la captura de la imagen AMI.

+1

+1 ... Me sorprende que esto suceda alrededor de 2,5 años después, ya que sería muy útil. Esto facilitaría mucho mi vida la resolución de problemas de mi compilación de Packer.

Pude superar esto en AWS usando protección de terminación en la instancia antes de que comience el chef-cliente. no es una opción decente pero bueno, funciona. Cualquier otra opción :)

+500: ¿por qué aún no está disponible esta función?

¿Quizás nosotros, como desarrolladores, podríamos intentar ensuciarnos las manos en lugar de quejarnos?

La solicitud de funciones no podría ser más sencilla.

• Leer una nueva opción de línea de comando ( --no-destroy-on-error )
• Agrega un if humilde en el lugar correcto. Pseudocódigo:

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

Lo intentaré. Y si funciona, no lo compartiré (principalmente para evitar solicitudes / quejas hipotéticas). El esfuerzo es algo bueno.

@vemv , básicamente ya resolví este problema con dos confirmaciones en https://github.com/orivej/packer/commits/debug-on-error-2.

@orivej ¡ Eso es increíble! He estado planeando agregar un --pause-on-error que creo que es la mejor manera de hacerlo (cuando un paso falla, espere a que se presione una tecla antes de limpiar, lo que permite al usuario iniciar sesión y solucionar problemas).

¿Podría abrir un PR con su código y podemos discutir los detalles allí?
CC @cbednarski

@vemv He estado siguiendo este tema durante algunos años. Solo puedo hablar por mí mismo, pero realmente no sé nada de Go, al menos no más que salir del paso y averiguar qué podría hacer el código. No me sentiría cómodo escribiendo código para algo tan utilizado como Packer, y mucho menos probándolo correctamente.

@orivej y @ rickard-von-essen, cualquier cosa que requiera la entrada del usuario realmente no me funciona, ya que solo uso Packer en herramientas automatizadas (es decir, Jenkins o TravisCI); Sé que también hay muchas otras personas en mi puesto. Creo que lo que realmente querría es algo que (1) tal vez aumente la verbosidad de la salida y (2) simplemente deje la máquina de origen (ya sea EC2, VMWare, lo que sea) en ejecución para que un humano pueda inspeccionarla después de la el trabajo ha fallado.

Actualmente, la depuración se detendrá entre los pasos, lo que requiere que presione Intro para continuar, por lo que siempre que sepa en qué paso está a punto de fallar, simplemente puede 'mantener' la máquina virtual allí para fines de depuración, pero obviamente eso no es tan bueno. Realmente desea que la plantilla siga todos los pasos para poder examinar el estado de error completo.

Solo agrego mi: +1 :. Realmente podría usar esta función.

@jantman Voy a hacer que packer -debug omita la limpieza cuando el proceso falle y no pueda obtener entrada (por ejemplo, con entrada de /dev/null ). Tenga en cuenta que la secuencia de ejecución del empaquetador se basa en la idea de que cada paso puede y se limpiará después, por lo que la terminación abrupta dejará el sistema en un estado que el empacador no podrá manejar por sí solo (por ejemplo, se quejará de que el directorio de salida ya existe), por lo que debe esperar tener que averiguar cómo hacer que su proceso sea repetible, pero esto probablemente sea fácil.

@ rickard-von-essen Actualizaré mi parche (agregaré nuevos proveedores) y realizaré una solicitud de extracción más tarde hoy.

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

Estoy creando Windows Box en AWS y tengo el volumen ebs "delete_on_termination" establecido en falso, por lo que después de una compilación fallida puedo [a] adjuntar el volumen, [b] iniciar una instancia, [c] mirar sus registros, [d] apaga la instancia, [e] desconecta el volumen, [f] elimina manualmente el volumen.

Noté que los archivos c:\windows\temp<guid>.out contienen la salida de la consola de los aprovisionadores de PowerShell que ejecuto.

Obtener este resultado es la única razón por la que tengo que tomar todos estos pasos adicionales para obtener esta información.

Sería genial si Packer admitiera algo como PACKER_CONSOLE_LOGS_COPY=$env:temp para que esos registros siempre se puedan recuperar (especialmente el último que falló) y yo pudiera evitar los pasos adicionales.

Para aquellos que comparten mi objetivo de compilar la última versión de desarrollo del empaquetador y al mismo tiempo integrar la solución anterior de orivej que se detiene en el primer error de compilación del empaquetador, aquí están los pasos que tomé y que funcionaron para mí.

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

Puedo confirmar que esto funcionó para mí y que el aprovisionamiento solo se detuvo cuando hubo un error.

No pude fusionar con éxito https://github.com/orivej/packer/tree/debug-on-error-2.

Tengo curiosidad, soy bastante nuevo en Packer y Git y este tema; ¿Hay alguna otra forma en que la gente haya estado implementando las correcciones de orivej luego de lo que he descrito? Es posible que me esté perdiendo algo muy obvio, así que avíseme si ese es el caso.

Solo verificando el estado de este problema.

¿Es que los cambios de

+1

Sería realmente útil, ahora mismo estoy usando un shell en línea con sleep 1800 para mantener viva la máquina virtual.
Implemente lo antes posible :)

Imho -debug está haciendo lo que todos necesitamos. Después de cada comando, debe presionar Enter para continuar con el siguiente. No enter = vm vivo :)

@noose : no me siento y veo la compilación; hay algunas secciones de ejecución muy larga (como la instalación del servidor SQL) que no me gustaría que se detuviera para la entrada del usuario. Me gustaría iniciar una compilación de prueba y cuando vuelva, tener algo que pueda depurar con un mínimo esfuerzo.

En mi humilde opinión, la depuración es totalmente inútil. Estoy ejecutando compilaciones complicadas y realmente no tengo la paciencia de presionar enter miles de veces hasta que llego al problema.
Realmente no entiendo por qué una función tan obvia como esta es tan difícil de implementar.

@ henris42, si bien estoy de acuerdo contigo en la inutilidad de -debug en este contexto, si parece una obviedad, ¿por qué no le das una oportunidad a una solicitud de extracción?

@noose , automatizo la compilación del empaquetador en un trabajo de Jenkins (que extrae de Git las configuraciones / scripts y los libros de jugadas de Ansible). Al usar el empaquetador de esta manera, un modo interactivo no es útil; es mucho más útil un análisis posterior a la falla.
Creo que este es un escenario común en el mundo de DevOps :)

Parece que todo el mundo necesita esto. La creación de estas AMI es propensa a errores y esta función haría que la resolución de problemas fuera menos lenta

Estoy de acuerdo con @worstadmin. En el caso de construir cajas Vagrant, puede abordar el problema desde múltiples ángulos (por ejemplo, mantener la máquina virtual alrededor, probar cosas con el aprovisionador nulo, etc.), mientras que las imágenes de Amazon son una raza especial y muy tediosas de depurar cuando hay un problema.

Combinado con https://github.com/mitchellh/packer/issues/1687 esto sería genial.

Además, a menudo es útil ignorar los errores de los aprovisionadores y dejar que continúen, especialmente durante la etapa inicial de desarrollo de una imagen, etc.

Casi 3 años después ... y todavía casi nada. Pasé los últimos días aplastándome la cabeza con un teclado tratando de hacer compilaciones de Windows complejas que fallan arbitraria y aleatoriamente en la ejecución de scripts de PowerShell sin salida y debido a la limpieza automática no puedo saltar a la instancia. Cuando ejecuto con -debug habilitado, las "pausas" adicionales introducidas al requerir la entrada manual parecen hacer que este problema no ocurra. Lo cual, pensarías que tendría sentido, solo agrego un montón de durmientes en mis scripts de PowerShell para simular esto, y eso no ayuda.

Ni siquiera mentir, le daré a alguien una recompensa de $ 100 por Paypal si alguien puede hacer una función de no destruir en caso de error lo antes posible y poner la bola en marcha en un PR para esto. Yo (y parece que cientos de personas más) necesito esta función, especialmente si se considera que el empaquetador se usa generalmente teniendo en cuenta la automatización (a través de CI / CD / etc.). Así que aquí está mi +1 largo y mi súplica.

Oye, podría haber una solución para un aprovisionador de shell, aunque no tengo idea de otros aprovisionadores. : crying_cat_face:

Lo tenía casi funcionando hoy, pero aprendiendo en Go No sabía que aterrizaría en el infierno de la metaprogramación nuevamente persiguiendo la interfaz a través de varios archivos para encontrar la implementación :(

¡Mira mi propuesta actual en el # 3885 que ya me parece bien!

@tmartinx :

Estoy tratando de ejecutarlo con Ansible, pero no funciona y el invitado KVM se ha ido después del error, por lo que no es posible ir allí para ver qué está mal ...

Como solución alternativa hasta que haya una nueva versión del empaquetador que contenga el número 3885:

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

Luego tiene 4 horas para ingresar a la VM que aún se está ejecutando y hurgar.

¿Qué diablos está pasando aquí?

• Packer detectó un 'Error desconocido' de VMware.
• _Packer_ me dijo que revisara el archivo de registro de VMWare para obtener más información. Se supone que el registro está en el directorio de salida.
• Pero _Packer en sí_ elimina el directorio de salida, por lo que no puedo verificar el registro. ¡Jaja! ¡Buena, Packer, bribón!
• Un montón de otras personas se han encontrado en una situación similar, como obviamente lo harían.
• La gente ha estado solicitando una solución aparentemente muy simple y obvia para este problema durante años.
• Un par de ellos incluso decidieron intentar solucionarlo ellos mismos. Parece que sus parches han sido rechazados por HashiCorp, o tal vez simplemente no tuvieron éxito.
• De cualquier manera, HashiCorp ha mantenido el silencio de radio. Parece que no van a arreglar esto nunca.

¿Vamos a concluir que el gobierno de los EE. UU. Ha ordenado mordazmente a HashiCorp y les ha dicho que no arreglen esto o algo?

Me está costando encontrar explicaciones alternativas.

Tuve la impresión de que las herramientas de HashiCorp son una buena opción para las cosas de DevOpsy en general, pero ahora lo estoy pensando mejor. Seriamente. ¿Nos estamos perdiendo algo obvio aquí, o HashiCorp simplemente está siendo súper turbio?

La razón por la que este ticket está cerrado es porque el problema ya se ha solucionado.

Agregue la bandera -on-error=ask a la línea de comando, y luego, si hay un error, se le preguntará si desea eliminar los artefactos de compilación o no.

Además, antes de responder a esta pregunta, puede ingresar a la VM y hurgar.

@ peterlindstrom234 , esto ya se ha implementado. Puede utilizar "-on-error = abort" y el empacador no debería realizar ninguna limpieza cuando se produce un error.

Muy bien, mi mal. Aunque seguro que tomó un tiempo extrañamente largo.

@ peterlindstrom234 tomó mucho tiempo debido a la orden de mordaza del gobierno de EE. UU.