-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FEATURE REQUEST: Common 'enabled' parameter for provisioners and post-processors #7864
Comments
Have you checked out our https://www.packer.io/docs/templates/provisioners.html#build-specific-overrides ? If those don't work for you, I'd like to hear a bit more about your template and your use case. tl;dr from the docs link above: You can make the provisioners skip by adding all the builds from a given template to an "except" statement.. Example: The below provisioner will print "this ran" if the
|
Yes, that works, but it's is not an obvious or nice solution. Example case: I had a case where I was using Chocolatey resource using chef-solo provisioner to install an older version of Elasticsearch. This worked initially fine, until an underlying dependency in Chocolatey broke and the install of Elasticsearch failed. If I can just disable 1 of the provisioners based on a variable than my problem is solved. |
This still seems like exactly the situation that the The way the Packer config is currently processed, we can't really do skips based on arbitrary variables. It would change the way we have to interpolate the templates. What you're asking for isn't really recommended practice but it's been asked for enough that we have a documented workaround here: https://www.packer.io/docs/templates/user-variables.html#making-a-provisioner-step-conditional-on-the-value-of-a-variable, or if you're feeling sassy you can probably create a wrapping script that preprocesses the Packer template with jq to remove the unwanted provisioner. I do understand that it would be a nice from a user experience perspective to have an explicit skip-based-on-a-variable option, and maybe it's something we can revisit once we have more developers on Packer but it's not something I have the bandwidth to pursue before then. I'd say "PRs are welcome" but honestly I need to spend some more time thinking through the implications of endorsing this as a first-class template option. I strongly prefer the idea of builders only being able to trace one pathway through provisioning; I think it's a better and more explicit practice, and that any repetition caused by having to create an extra builder is worth the explicitness that's gained. Thanks :) |
I hear what you're saying. The way I currently get around the problem is in the line of https://www.packer.io/docs/templates/user-variables.html#making-a-provisioner-step-conditional-on-the-value-of-a-variable (running chef-solo provisioner with an empty run-list). UPDATE: |
doing some cleanup -- this one was kind of a dupe of #4895 |
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. |
After using packer for a while, I came to the conclusion that it's not easy to skip provision steps.
I had a chef-solo provisioner which only had to be executed in certain cases. I ended up basically running the provisioner without a recipe in cases where I wanted to skip that step. A bit clunky.
It would've been so much easier if there was a common 'enabled' parameter available which by default = 'true'. Setting 'enabled' to 'false' would result in this step to being skipped.
Same would be handy for post-provisioners as well.
The text was updated successfully, but these errors were encountered: