Same issue, weird: https://i.imgur.com/QDngHot.png

I even don't understand the logic behind: "if no variable with the given name, then just... using variable reference text instead." )) why not empty string or "<null>". If there "<NOT FOUND>" happens would be much more useful

Hi everyone.
I see a new step called "Variables - Find Unreplaced"
Searches Web.config or App.config files looking for Octopus Deploy variables that have not been replaced. Alternatively, any arbitrary file can be checked.

https://library.octopusdeploy.com/step-template/actiontemplate-variables-find-unreplaced

It looks like this step template is something that that could be modified to throw an error if any unresolved variables and fail the deployment. It's from 2015, but the code looks solid.

Just chiming in with a "me too", but with a request to extend this beyond file substitution, and include variable references in Step parameters (and nested variable references / #{if} expressions).

Basically, fail the deployment as soon as possible if a reference is found to an undefined variable anywhere that "Variable Substitution Syntax" can be used. This could be done before the deployment even starts for nested variable definitions and Step parameters, but might only be possible at runtime for file substitutions.

See https://help.octopusdeploy.com/discussions/problems/70371-validating-that-all-variables-are-defined-in-a-deployment for a support forum request I posted before I found this uservoice suggestion.

For context, I've been troubleshooting an issue with a deployment that appears to be creating incorrect tags in an Azure Resource Manager deployment. When I look in the Azure portal, the resource created by the deployment has a tag called "MyTag" with the literal value "#{MyTag}".

From a quick investigation, it looks like my Octopus Deploy Project doesn't have a variable called "MyTag", so the file substitution on the ARM Template is failing to replace the literal "#{MyTag}" text with the value of a variable. I can obviously fix this by adding a "MyTag" variable to my specific Project, but it doesn't help with the general problem of identifying when variables are undefined in a deployment.

Cheers,

Mike

We've had a similar problem a couple of times with our deployments and we came up with a fairly robust workaround.

But before I tell you that story, let me explain why we think this is an important feature.

Every so often, when a key in the settings file gets changed the programmer might forget to update the matching variable in Octopus. The app will happily deploy to production but the variable in question will have the *wrong* value. For example, lets say I have a config file with a database connection string defined something like this:

```json
{
"MyDatabase": "Server=dev-server;Database=dev-database;User Id=devuser; Password=myPassword;"
}
```

We deploy our app to the CI environment and everything appears to be working okay. Then we deploy through to Production and again, the app appears to be working okay. The next day, one of our users emails us and says "where's my data?".

Oh, crap. The app is running in Production but the database is pointing at our dev database. How did this happen.. after some investigation we figure out that the "MyDatabase" variable was renamed to "MeDatabase" and Octopus didn't replace it with the Production connection string on deployment. We quickly scramble to fix the issue and redeploy the app. Phew!

The next question is, how can we prevent this kind of thing happening again? Unfortunately, it's quite a tricky problem. Octopus doesn't really know if a variable in the settings file should be replaced or if it should even exist. Some variables apply to some apps and not others.. gah.

Problem 1: Can we prevent the Production app from running with development values?

What we did to solve this problem is write a custom step in the deployment process that replaces ALL variables in the appsettings.json file with null values *before* Octopus replaces them with real values. This way if Octopus fails to replace the variable it will be null and the app will (probably) fail at runtime. It's not ideal, but we feel that a failing app is better than one that *appears* to be working but is actually *wrong*.

Problem 2: Can we prevent the app from actually deploying if Octopus fails to replace any variables?

To solve this problem we wrote another custom script that goes through each of the variables and checks to see if any still have a null value after Octopus has attempted to replace them. If any variables failed to get a value, we fail the deployment.

*Note*: One caveat to this approach is that *every single variable* defined in the appsettings.json file *must* also be defined in Octopus. We had to do some clean up in our settings files to make sure this was true. We came to the conclusion that a setting isn't really a setting if it doesn't actually change value in any environment, so we removed it from the settings file and configured those ones in code instead.

Please make it an option to fail the deploy if any variable wasn't substituted for any step template that does variable substitution (e.g. we have same issue for Deploy Azure Resource Group step). It would be a pain to have to find it out in production environment.

Or at least make it an option using Octopus system variables.