Weird behaviour when setting TF_ENCRYPTION with a heredoc and exporting it with ##vso[task.setvariable in Azure DevOps Pipelines #2991
-
|
(don't know if bug or I'm stupid) Hey, I split tofu init validate, plan and apply into multiple tasks. tofu apply actually into another job. So i create the the TF_ENCRYPTION var before running init and pass it to the other steps and jobs via the setvariable task. This is me writing the variable During testing i luckily used some dummy values for my keys because I was very confused when I saw DevOps partially print out the variable to my pipeline logs. Specifically it cut off the first line of the heredoc (first key_provider line), printed the rest out to the logs and then saved this rest into the variable. So, does TF_ENCRYPTION actually need this formatting or can it also be just a one line string? Haven't tested it yet. Even if this is DevOps specific, we might want to add a small note on the docs on how some pipelining solutions might handle multiline variables not as expected. I thought I can just copy paste the example. There are certainly ways to not run into this issue, I know. I just wanted to highlight this edge case. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
Hi @mardonner, HCL's native syntax, which is what you're using in your current example, does require there to be real newline characters delimiting the block boundaries and the individual arguments in the blocks, and so you won't be able to turn that into a single-line string while continuing to use that syntax. (There is a narrow exception for a single block that contains only a single argument, but your configuration doesn't fit that constraint.) However, the documentation for The documentation section JSON Configuration Syntax describes how the JSON structure relates to the native syntax structure. That page is written primarily for the language used in Directly editing minified JSON doesn't seem like much fun, and so you might prefer to generate that final JSON string from something else instead. I don't know what other software you have available in this execution environment, but for example you could pipe a more readable JSON representation (with newlines and indentations) through |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed response! Ah, I should actually search through the documentation more instead of relying on SEO. I see, my proposed warning was already there. Ok, using json syntax is way better than what I was thinking about (base64 -w 0 encoding -> task.setvariable -> running export TF_ENCR... with base64 decoding). Two more questions:
This also relates to the second question:
|
Beta Was this translation helpful? Give feedback.
-
|
When you pass a filepath to The "partial configuration" mechanism for backend configuration is implemented in terms of the HCL data model (arguments and nested blocks) rather than the raw syntax details, so as long as your JSON document describes equivalent settings as the native syntax file did then the merging behavior would be the same. The CLI configuration (what you called If you run into something that behaves strangely then please let me know the details and I'll try to help with that specific problem, since unfortunately the translation rules vary slightly between for different parts of the CLI configurage language for historical reasons. This older version of HCL will try to parse as JSON if the first non-whitespace character in the file is |
Beta Was this translation helpful? Give feedback.
-
|
Interesting. Thanks for the explanation. I'm in no rush to move entirely to the json syntax for these files but I'll keep that in mind if I ever do. |
Beta Was this translation helpful? Give feedback.
Hi @mardonner,
HCL's native syntax, which is what you're using in your current example, does require there to be real newline characters delimiting the block boundaries and the individual arguments in the blocks, and so you won't be able to turn that into a single-line string while continuing to use that syntax. (There is a narrow exception for a single block that contains only a single argument, but your configuration doesn't fit that constraint.)
However, the documentation for
TF_ENVIRONMENTsays that it also accepts JSON syntax, and so you could potentially use minified JSON to populate that environment variable and thus the result would be only a single-line string.The documentation …