Request for looser checking of builder names in provisioner only/except/override clauses

[styro]

When I use a builder name that is interpolated at runtime (ie containing user variables) I can't match the various name combinations in provisioners.

Provisioner matching using the actual runtime builder name fails at template validation/parsing time because there is no builder defined in the template that matches the names in the provisioners.

Would it be possible to change those failures to warnings? That way a single builder could make several different types of images based on which provisioners it matches.

This seems similar to #858 but I think that issue only fixed matching interpolated builder names from the CLI rather than in the provisioners.

[cbednarski]

Thanks for opening a ticket. Does this work if you use -only in addition to -var?

I think in the -only case we can make the validation more granular without making it pass builds that are guaranteed to fail. In this case a warning is irrelevant.

[styro]

No, using -only makes no difference.

As an example of what I'd like to achieve is to have one builder produce one of four combinations (ie 2 variables with 2 possible values each) of images without having to duplicate the builder four times. A cut down example:

{
  "_comment": "foo could be 'nofoo' or 'yesfoo', bar could be 'nobar' or 'yesbar'",
  "variables": {
    "foo": "nofoo",
    "bar": "nobar"
  },
  "builders": [{
    ...
    "name": "prefix-{{user `foo`}}-{{user `bar`}}
    ...
  }],
  "provisioners": [
    {... (foo stuff) ... , "only": ["prefix-yesfoo-nobar", "prefix-yesfoo-yesbar"]},
    {... (bar stuff) ... , "only": ["prefix-nofoo-yesbar", "prefix-yesfoo-yesbar"]},
    ...
  ]
}

An example error output:

 ui error: Error initializing core: 10 error(s) occurred:

* provisioner 1: 'only' specified builder 'prefix-yesfoo-nobar' not found
* provisioner 1: 'only' specified builder 'prefix-yesfoo-yesbar' not found
* provisioner 2: 'only' specified builder 'prefix-nofoo-yesbar' not found
* provisioner 2: 'only' specified builder 'prefix-yesfoo-yesbar' not found
...

Using -only still fails the same way when parsing the template because the provisioners are referencing builder names that don't exist.

What I'm hoping for is that the provisioners only clauses get evaluated later after the builder name is interpolated, and the provisioners decide to run if the builder name matches just one of them even if some of the other builder names don't actually exist during this run. except would work the same way, just that it wouldn't run if one of the builder names matched.

Hopefully that makes a bit more sense. The alternatives seem to be lots of template duplication or maybe generating the templates on the fly with a script of some sort.

[mpictor]

It's a shame this isn't fixed! I'd hoped to avoid having multiple identical builders by setting the builder name from a user variable - but it sounds like this blocks that use case. 😞

[cgoeller]

A fix for this issue would be very useful. +1

[dannyibishev]

+1 to get this going as well (A useful feature to have and would save us the ability of recreating a duplicate file.)

[bleloch]

+1

[jcoconnor]

+1 - would be extremely useful too.
This request has been up for quite a while !!!!!

[SwampDragons]

I'm sorry that this hasn't been prioritized, but PRs are always welcome!

[pure-yesmat]

Could we also allow the only and except texts to be interpolated/templated?
example:

{
    "variables": {
         "foo": "nofoo",
          "version": "1.0"
    },

   "builders": [
        {
               "name": "{{user `foo`}}-{{user `version`}}"
        }
    ],

    "provisioners": [
        {
            _stuff_,
            "only": ["yesfoo-{{user `version`}}"]
        }
}

So this would limit the provisioner to all versions of yesfoo.

[SwampDragons]

I'm doing some issue cleanup; this is basically a duplicate of #4895 which I think is a bit broader in scope, so even though this issue predates that I'm going to close this as a duplicate of that one.

[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.