Ben Pearce on 02 Feb, 2018 06:51 AM
Thanks for getting in touch.
So that I can help you, can you explain which variables you are trying to compare and what you are trying to achieve.
Are the live variables the ones in the web.config on the deployment target, or are they the variables from the last release?
The sensitive variable values are not returned via the API at any stage time, the only thing the API will tell you is if the sensitive variable has a value or not.
Since you are using Octopus.Client, I assume you are running this from outside Octopus, not as part of a deployment step. If you were trying to run something like this inside the context of a deployment step, you may have access to the variable values although this is not always the case, such as output variables which only exist after the step has completed, or account variables which only get evaluated with the step they are referenced in.
If you can get back to me with some further details, I can try and help you find a solution.
I’m using the octopus client from a powershell cmdlet, written in c#. We want to compare all variables assigned to the project and library variable sets in the previous release to a given environment, to the release we are about to push to that environment. The main use case here is ensuring that critical data such as database connection strings, API keys, encryption keys etc have not been accidentally re-scoped so they won’t be deployed to the live environment, or just modified. We need deployers to be aware if they are about to change the API key or connection string, which they currently have no visibility on.
From what I understand, if I wrote this as a deployment step, then I’d be able to access the variables for the release that was being executed, but there would still be no way of accessing the sensitive variables for the previous release. Is that correct?
We do not need to consider output variables, and I’m not sure what account variables are, to be honest.
Ben Pearce on 06 Feb, 2018 01:37 AM
You are correct, you cannot access the sensitive variables from a previous release via the API.
You won't be able to query the passwords across releases directly in the database either as the passwords are encrypted each time and the resulting encrypted string is different each time. All other non-sensitive values are available via the API or database.