terraform init using backend-config

[fulgas]

Is it possible to use backend-config as a key value map to configure the backend?
For example, this is what i use to set the backend_config and cant seem to find a way to do it on the action.

'-backend-config="storage_account_name=${{ env.TF_CLI_STORAGE_ACCOUNT_NAME }}" -backend-config="container_name=${{ env.TF_CLI_CONTAINER_NAME }}" --backend-config="resource_group_name=${{ env.TF_CLI_RESOURCE_GROUP_NAME}}" --backend-config="key=${{ inputs.backend_config_key }}.tfstate"'

[rdhar]

Hey @fulgas, this is a great shout, thanks for raising! As it happens, TF-via-PR does support the key-value map for -var input, but not yet for -backend-config.

One complicating factor for this is that -backend-config input is used for naming the plan file artifact uploaded by the workflow. Unfortunately, GitHub enforces a limit a 256 characters for the artifact name. As you can imagine, we reach that limit pretty quickly by just passing in a couple lengthy arguments.

That's not to mention that , is used as a separator, so none of the arguments can include a comma—which may or may not be within one's control.

While my current recommendation is to save these argument combinations in various backend configuration files like so, and provide the file path dynamically to arg-backend-config input similar to working-directory here.

However, I have raised #351 to track this request and I'm keen to get your thoughts on:

• How to handle plan file naming when it exceeds the 256 characters?
  • Perhaps truncate and warn the user of the risk of non-unique artifacts?
  • Are there simple 2-way encoding methods to reduce character count, while still being able to decode back?
• Is feasible to use backend configuration files in place of passing in arguments to the CLI directly?

[fulgas]

Hi @rdhar, that for the fast reply.

As a workaround im using the TF_CLI_ARGS_init instead of using the parameter and it works as intended.

Regarding your questions, should the PR number and the working-directory/ch-dir be enough to identity a plan? Or you can throw a bunch of parameters and generate a base64?

[rdhar]

That's such a smart workaround, I keep forgetting it exists—thanks for reminding me, I should document it somewhere!

I have a couple positive updates regarding the original request and solution:

• A combination of PR number and working-directory/-chdir alone isn't enough to unique identify plan file artifacts.
  • Someone could pass different -var-file paths or even workspace inputs, like in this example workflow.
  • As a result, the artifact name has to include a number of crucial arguments to ensure it uniquely identifies a particular configuration.
• Unless I'm doing something wrong, all of my attempts at base64 encoding has resulted in longer file names than supplied!
• As for the currently-adopted solution, my original premise of "2-way encoding method" was incorrect—TF-via-PR doesn't need to decode the file name during apply, it just has to find a match. That breakthrough led to the use of MD5 hashing for concise, fixed-length string output, which is perfect for our use-case.

This has already been merged to main branch, and a new patch version will be released shortly, after which you should be able to pass in the following:

arg-backend-config: storage_account_name="${{ env.TF_CLI_STORAGE_ACCOUNT_NAME }}",container_name="${{ env.TF_CLI_CONTAINER_NAME }}",resource_group_name="${{ env.TF_CLI_RESOURCE_GROUP_NAME}}",key="${{ inputs.backend_config_key }}.tfstate"

Note, since this is a , comma-separated list, the values themselves can't contain commas.

[rdhar]

Happy to announce this is shipped with v12.0.5, where you've been credited for your contribution!

Please consider ⭐ this project, if you find it useful.