Hi, I am attempting to use Octostache to output a human readable message from a terraform plan step, which is recorded using JSON.
I have a “Plan to apply a terraform template step” in my process which has the output format set to JSON. I have this configured so I can use the add/change/remove counts as a variable run condition on a manual intervention step, which is used to have a human approve the changes before continuing with the terraform apply.
Similar to this documentation: Planning changes made by Terraform templates - Octopus Deploy
The messages are written to the JSON object with the name @message, which I can’t seem to figure out a method to reference them. Here is an example of one *.[step].Output.TerraformPlanLine
{"@level":"info","@message":"Plan: 0 to add, 0 to change, 0 to destroy.","@module":"terraform.ui","@timestamp":"2023-01-30T16:41:45.572476+10:00","changes":{"add":0,"change":0,"remove":0,"operation":"plan"},"type":"change_summary"}
I have tried to reference the “@message” attribute in a number of ways, but would like to know if there is a way to reference it?
I created an example of the methods I have tried using the Octostache library here: Octostache JSON example | C# Online Compiler | .NET Fiddle
If it is not possible to reference the @message attribute, is it possible to return a plan text output of the terraform plan as well as the JSON counts for the add/change/remove values?
Thanks for getting in touch! I’m sorry for the unexpected behavior here with referencing JSON attributes with an @ symbol. I greatly appreciate the level of detail in your report. I’m also seeing the same result, and haven’t managed to find any syntax to do this, so we’ve raised this internally to hopefully get an answer soon. I’ll keep you posted, and please let me know if you have any questions or concerns in the meantime.
An update with the internal discussion brought up with the engineers - it’s been pointed out that the parsing of identifiers doesn’t include the @ symbol which looks to be the reason why it doesn’t get selected properly. This also doesn’t work natively when doing a standard substitution of a variable with this character (e.g. a variable named @foo with the Octostache syntax of #{@foo}).
They are thinking of creating an issue on the Octostache repo so they can do some testing, as we can’t foresee any reason we shouldn’t extend it to include @ at this point. I’ll let you know if there’s any other updates going forward.
I appreciate you bringing this to our attention. If you have any other questions or concerns, don’t hesitate to shout out.
