Feature: the ability to enable/disable individual builders/provisioners/post-processors

[ladar]

The idea is simple. Add a global enabled option, along the same lines as only and except to builders, provisioners, and post-processors, which if set to false, would cause packer to process the template as if the curly braced section didn't exist. Presumably if a builder was disabled, the dependencies would also be skipped, but any only or except rules referencing the build name would NOT cause a validation error. Note that if the enabled option is missing, a default value of true is implied.

I shall present two use cases. As you know, I'm currently maintaining base boxes for 25 different distros. I've run into issues, where for some reason, a distro repository gets broken. In the last couple of months this has happened twice... when the Ubuntu archive was missing a significant number of v16.10 packages, and the second, when several Alpine packages reached the mirrors without valid signatures. See:

https://bugs.launchpad.net/ubuntu/+source/ubumirror/+bug/1776546

And:

http://lists.alpinelinux.org/alpine-devel/6195.html

For more details. Since my templates have all 25 boxes defined (I separate based on the org/hypervisor), it would have been nice if I could have disabled the offending configs until the issue was fixed upstream, without removing them entirely, or having to add an except rule every time I ran packer.

The second use case involves the vagrant-cloud plugin. Like many, I use that plugin to upload my boxes to the vagrant cloud, and like many, my templates are public (see roboxes), so that others may use them directly. Since others obviously can't upload the boxes to my organization, it would be nice if I could disable those config sections, without removing them, as they only cause spurious errors when others try and build my templates.

Presumably the enabled boolean would be global, and work every where, as I can imagine others would like the ability to disable provisioning steps, etc. If forced to choose, then builders/provisioners/post-processors are likely the most important.

With disabled build configurations, it should be possible override and build a disabled configuration with the -only=box command line option. It should also be possible to override the flag globally. I present two possible methods. The first would be to use the -force option override the flag. The second and preferable method would be to add support for "default" variable values. If this existed, I could set a default value to false and then override the value by adding an environment variable, or command line -var or -var-file value. Something along the lines of:

{
  "variables": {
    "flag": "{{ default `false` | env `ENABLED`}}",
  }
}

This way, if the ENABLED environment variable is missing, the value of flag would default to false.

For completion, a couple of examples, with the enabled flag set to false. Naturally if default values were supported, the value would be a user variable.

Build configuration:

{
  "type": "qemu",
  "name": "generic-ubuntu1610-libvirt",
  "enabled": false,
  "vm_name": "generic-ubuntu1610-libvirt",
  "output_directory": "output/generic-ubuntu1610-libvirt",
  "accelerator": "kvm",
  "qemu_binary": "/usr/libexec/qemu-kvm",
  "boot_wait": "20s",
  "boot_command": [
    "<esc><wait>",
    "<esc><wait>",
    "<enter><wait>",
    "/install/vmlinuz ",
    "initrd=/install/initrd.gz ",
    "auto-install/enable=true ",
    "debconf/priority=critical ",
    "preseed/url=http://{{.HTTPIP}}:{{.HTTPPort}}/generic.ubuntu1610.vagrant.cfg<wait> ",
    "<enter>"
  ],
  "format": "qcow2",
  "disk_size": 32768,
  "disk_discard": "unmap",
  "disk_cache": "unsafe",
  "disk_compression": true,
  "disk_interface": "virtio-scsi",
  "net_device": "virtio-net",
  "qemuargs": [
    [
      "-m",
      "2048M"
    ],
    [
      "-smp",
      "cpus=2,sockets=2"
    ],
    [
      "-drive",
      "if=none,file=output/generic-ubuntu1610-libvirt/generic-ubuntu1610-libvirt,id=drive0,cache=unsafe,discard=unmap,detect-zeroes=unmap,format=qcow2"
    ]
  ],
  "http_directory": "http",
  "headless": true,
  "iso_url": "http://old-releases.ubuntu.com/releases/16.10/ubuntu-16.10-server-amd64.iso",
  "iso_checksum": "72b0d421da77f1e0c549b4efe6fc6c184e9909d6792f0d1e59b56d63e9705659",
  "iso_checksum_type": "sha256",
  "ssh_username": "root",
  "ssh_password": "vagrant",
  "ssh_port": 22,
  "ssh_wait_timeout": "3600s",
  "shutdown_command": "echo 'vagrant' | sudo -S shutdown -P now"
}

Vagrant cloud configuration:

{
  "type": "vagrant-cloud",
  "enabled": false,
  "only": [
    "generic-alpine37-hyperv"
  ],
  "box_tag": "generic/alpine37",
  "version": "{{user `box_version`}}",
  "version_description": "A generic Alpine v3.7 base box."
}

While I've had this idea for awhile, the forgoing essay was written to keep the @SwampDragons happy. See pull request #6357.

[SwampDragons]

And I so appreciate it :)

[SwampDragons]

After going through and cleaning up a bunch of old issues, I found that this is a duplicate of #2679; I'm working on roadmap right now and I'm planning to get this on there. Meanwhile, I'm going to close this since there's more activity on the other issue.

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