I was trying to use the JSON Configuration variables feature in the Deploy Site process - and could not get it to work.
Very simple situation, I wanted a file to be available on my resulting site to contain the a build value (set before reaching Octopus) and then the Octopus release number. This would allow a developer or devops to simply check this file and know that both build and release had refereshed the site (even when there were no visual changes).
So the JSON file was simply:
{“version”:“1.0.3-180”, “octopus”:""}
I wanted the second value with the Release Id - no combination of varible name or scope could get the file to contain anything except the “”. I know that the json file was detected because entering an incorrect path showed as an error in the deploy site step.
There were a few comments on other questions, but they generally end up with "you could (some even implied you should) use the “Substitue Variables in Files” option instead.
Thanks for getting in touch! I think the issue you’re hitting here is the name octopus that’s being used is a reserved word. If you named it something else, does the value get substituted in correctly? For example, having your JSON file look like {"version":"","releaseid":""} and changing your project variable name to match.
I hope this helps get you going. If you’re still hitting this issue after the variable name change, could you send us through a copy of your verbose deployment logs with debugging variables enabled? That should shed more light on why you’re hitting this snag, and the following doc page outlines the process to produce and export this log.
@Kenneth_Bates - thanks for the quick reply, glad I asked.
Yes you were right, any field name that started with “Octopus” was ignored (well I tried two… so that might not be the actual rule).
Please, please can a warning be added into the deployment log so that it can be fixed quickly? The warning about not finding the file was really easy to spot, and if the “invalid” variable name had been flagged in the same way, I would have only spent a few minutes on this.
Thanks for following up and letting me know! I tend to agree that this situation should add a warning in the logs to be explicit into why this is occurring. I’ve brought it up with my team, and we’re currently discussing how this could be implemented.
Let me know if you have any further questions or concerns moving forward!
