Packer: Add a --fail-fast behavior to build

Created on 19 Mar 2020  路  1Comment  路  Source: hashicorp/packer

Please search the existing issues for relevant feature requests, and use the
reaction feature
(https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/)
to add upvotes to pre-existing requests.

Feature Description

When building multiple (AMIs) at the same time, if one fails the rest of the build process continues all the way to baking the final AMI. I suggest we have a notion of a --fail-fast argument. Where in if any part of a stage of the build process (defined by the same pause points as --debug does) fails, we cancel all builds immediately and clean-up as on-error dictates.

Use Case(s)

Mostly this would be useful in CI/CD environments or building new sets of images. If I'm targeting multiple OSes and one fails to build for whatever reason. Nothing after that matters to me. Either the whole build completes successful or it did not. Waiting till the end and having to clean-up the successful build just slows things down.

enhancement help wanted

Most helpful comment

Hi, thanks for opening this! I can see how this would be useful in your use case.

We probably won't prioritize work on this feature, simply because you can probably work around it using a wrapping script that calls the builds individually and tracks their progress, or by running each separate os build in your template in its own parallelized ci job (for example, one OS build in each parallel "stage" https://jenkins.io/doc/book/pipeline/syntax/#parallel if you use jenkins with failFast set)

I know that's a little extra legwork on your end, and in an ideal world we'd give you the option internally, but right now we're focusing on features and bugs that can't be worked around.

That said, if a community member wants to contribute a PR, I'd happily review it.

>All comments

Hi, thanks for opening this! I can see how this would be useful in your use case.

We probably won't prioritize work on this feature, simply because you can probably work around it using a wrapping script that calls the builds individually and tracks their progress, or by running each separate os build in your template in its own parallelized ci job (for example, one OS build in each parallel "stage" https://jenkins.io/doc/book/pipeline/syntax/#parallel if you use jenkins with failFast set)

I know that's a little extra legwork on your end, and in an ideal world we'd give you the option internally, but right now we're focusing on features and bugs that can't be worked around.

That said, if a community member wants to contribute a PR, I'd happily review it.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

s4mur4i picture s4mur4i  路  3Comments

Nikoos picture Nikoos  路  3Comments

tleyden picture tleyden  路  3Comments

wduncanfraser picture wduncanfraser  路  3Comments

brettswift picture brettswift  路  3Comments