flag to skip postprocessor

[rrva]

I'd like a flag to skip certain postprocessors, for example atlas when I only want to do a local build.

[rrva]

Similar to -only:

packer -postprocessors vagrant

will only run the vagrant postprocessor

[ghost]

2nd this. I know docker really wants us to use dockerhub but I don't have any need for that.

[robertrossmann]

👍

Yes, this would be a welcome addition. I frequently find myself testing my builds locally to catch any errors before I am ready for publishing and so far I had to manually remove the atlas post-processor when I wanted to only do a local build.

[mwrock]

👍 yes. this would be a welcome feature

[simbo]

+1
Yes, please.

[mvermaes]

👍

Currently we maintain two templates, one to generate AWS/Vagrant images via Atlas, another with the details required for the vSphere postprocessor (which is otherwise identical to the Atlas one).

[sharumpe]

+1

We also maintain two .json files: one for vagrant box build for testing and one for vSphere. It would be wonderful to be able to overload -only= or add -only-post= (or similar) to limit the post-processor.

[bdwyertech]

👍

[wyaeld]

@cbednarski any love for this? Seems consistent with the DRY design.

Only comment I would make it that potentially rather than referring to provisioners/builders/post-processors by type, being able to 'tag' them, and filter the tags to run would give more flexibility, and its a pattern used successfully in some other tools.

eg.

packer build -tags vmware my-packer-template-with-everything.json

packer build --help
...
Options:

  -tags=foo,bar,baz         Only include the builds, provisioners and post-processors that match the tags
...

[cbednarski]

Thanks for the suggestion, folks. This sounds like a good feature addition to me, but it's not on my short list right now.

rather than referring to provisioners/builders/post-processors by type, being able to 'tag' them, and filter the tags to run would give more flexibility

I like this idea. At least from a UX perspective this is a nice way to do things since you won't need to remember a bunch of different flags. At first glance I think we may be able to overload -only to use tags or builds. By default nothing will have a tag (and tags will not exist in anyone's build templates) so it should be backwards-compatible. Need to consider some of the compound cases here before committing to this, though.

[steve-jansen]

Ran into this problem with local packer builds that include an Atlas post-processor.

As a one-liner workaround, the awesome jq can strip the post-processor block, then pipe it via stdin to packer...

jq 'del(."post-processors")' packer.json | packer build -

[bdwyertech]

Thank you sir @steve-jansen, didn't know jq existed. Great addition to the arsenal.

[bdwyertech]

It seems stripping post-processors caused no build artifacts to be produced, not even a local box. If you want to target a specific post-processor, use this jq '.["post-processors"][0] |= map(select(.type != "atlas"))' packer.json | packer build -

Credit goes to @parkershepherd

[marcusportmann]

+1

Also struggling with local packer builds that include an Atlas post-processor.

[panpan0000]

+1

[pierreant-p]

+1

[rverchere]

+1

[awiddersheim]

+1

[lfarnell]

please don't +1 in a comment. Please use a reaction stead. It generates unnecessary emails when a +1 comment is made

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.