Packer: Feature Request: required variables settable through environment

[hubertgrzeskowiak]

Right now we can either specify a user variable as null which means it's required and it can only be set using the CLI option, or we can use {{env `foo`}} to make it settable through the environment. I am missing an option to set a variable as required, with the option to set it through the environment.

Sidenote: Terraform offers this functionality. There all variables are required by default and can be set using the TV_VAR_ prefix for environment variables: https://www.terraform.io/docs/configuration/variables.html#environment-variables

[SwampDragons]

So to clarify, you want to be able to have Packer check for environment variables if the variable isn't already set inside your packer config?

[hubertgrzeskowiak]

@SwampDragons so my issue is the following. Let's say you have one Packer variable called access_key which is required.

You define it in Packer like this:

{
  "variables": {
    "access_key": null,
    ...

Now that variable is required and the only way to provide it is through command line, e.g.:

packer build -var "access_key=${ACCESS_KEY}" packer-conf.json

This call has some big downsides: it requires you to know all variable names defined in the packer file, it requires you to assemble a specific command line call rather than using a generic one - as it's common practice in more automated systems. Also the long command line becomes unreadable quickly .

What I can do in Packer instead is the following:

{
  "variables": {
    "access_key": "{{env `ACCESS_KEY`}}",
    ...

Now I can define my variables independently of the command line call, and I can access commonly known environment variables (e.g. AWS_ACCESS_KEY_ID or the like). The call is just simple:

packer build packer-conf.json 

While this solves a problem, it introduces a new one: what if my environment variable ACCESS_KEY is not set at all? Packer will just use an empty string. Sure, I can check for it in a provisioning step, but those are run late in the process, and I need to explicitly test for them. If I were to use any of my variables in the builders, I cannot check for them being set.

I wish I could tell Packer: "This variable can be set through command line, or environment, but it has to be set one way or another!"

Just to recap, I am not suggesting changing Packer's way of handling user variables in a backward incompatible way. I am suggesting adding some syntax to mark user variables as required, while preserving the possibility to set them through the environment.

[SwampDragons]

Okay, I can see the benefit of that. It's a good idea. Off the top of my head, I'm not totally sure how easy it will be to implement because of the way Packer's architecture handles variables, so I'll have to take a look at that before deciding if it's something we can prioritize soon.

Meanwhile, have you considered using a var-file? This solves the issue of long and non-generic command lines, and gives you a fair amount of flexibility.

[akumria]

I think the simplest way would be to assume that if an environment variable is empty, then default the value to be null this triggering the requirement that the value is actually set.

[SwampDragons]

I think we may get this behavior "for free" as part of the HCL2 config effort that we're hoping to land this year.

[azr]

Hello there this is implemented in #8588; only for hcl2 but basically after defining a variable; one will be able to set it by setting an env var like so: PKR_VAR_variablename.

[hashibot[bot]]

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.