Packer: Packer HCL Environment Variables without PKR_VAR_

[kclinden]

Description

When using CI/CD tools such as Jenkins or CodeBuild you may want to reference environment variables that are not managed by the user. The specific example that I am looking at is getting the Git Repo URL and Commit ID from AWS CodeBuild which are stored in CODEBUILD_SOURCE_VERSION and CODEBUILD_SOURCE_REPO_URL.

When doing the HCL2_Upgrade the input variables resulted in the following:

variable "git_commit" {
  type    = string
  default = "${var.CODEBUILD_SOURCE_VERSION}"
}

variable "git_repo" {
  type    = string
  default = "${var.CODEBUILD_SOURCE_REPO_URL}"
}

Under JSON this works with the following:

    "variables": {
        "git_repo": "{{ env `CODEBUILD_SOURCE_REPO_URL`}}",
        "git_commit": "{{env `CODEBUILD_SOURCE_VERSION`}}"
    }

Current Error on validation

Error: Variables not allowed

  on packer-windows-2016-amazon-ami.json.pkr.hcl line 21, in variable "git_commit":
  21:   default = "${var.CODEBUILD_SOURCE_VERSION}"

Variables may not be used here.

Error: Variables not allowed

  on packer-windows-2016-amazon-ami.json.pkr.hcl line 26, in variable "git_repo":
  26:   default = "${var.CODEBUILD_SOURCE_REPO_URL}"

Variables may not be used here.

Use Case(s)

Leverage CI/CD created Environment Variables

[azr]

Hello there, thanks for opening. All env vars must be prefixed with PKR_VAR_, this is to make sure these var were explicitly defined to be used by Packer as input values and for safety reasons.

One thing you can do is :

PKR_VAR_CODEBUILD_SOURCE_VERSION=${CODEBUILD_SOURCE_VERSION} packer build ... along with:

variable "CODEBUILD_SOURCE_VERSION" {
  type    = string
}

So that you can call "${var.CODEBUILD_SOURCE_VERSION}"

[azr]

To add a little info to this, when we implement build chaining in packer or may be the ability to invoke something like a packer module from a packer module then we would like this submodule to be able to work without forcing the starter to have to set env vars from the submodule hence the strong push onto not supporting env variables from a template file.

Note: currently we don't know if there is going to be something like a packer module at all ( I'm personally pretty much looking forward for Packer to have that) but it's way easier to say no now -- and think a bit more -- than to deprecate it later on.

[azr]

Hello there ! Just to say we've given this some thoughts and decided to make the env function available as a default for input variables. It's not so dangerous and the operators should know what they are doing, also lots of users will probably have this exact same issue since you had it, making easier to upgrade.

About Packer submodules: we will see when we get there but currently we expect these to work as well, mainly because we could be thinking of these as "well known variable" like AWS_DEFAULT_REGION and therefore one could expect them to work down there too if required, etc.

[kclinden]

Awesome that is great news.

[SwampDragons]

You'll be able to use an env function in HCL once #10240 is merged.

[zfouts]

That's fantastic news, thank you!