Cannot stop deployment from searching every config file

I only want the deployment to search the config files named after my environments, such as web.development.config. However, Octopus will search each config file that it finds. In the “Enabled Features” section of my IIS Web Application step (child step), I have “Configuration variables” unchecked and “Configuration transforms” checked (see attached image).

To resolve this, I can make any sort of change in my IIS Web Application child step, Save it, and Octopus will only search the config files named after my environments instead of all of them, which is what I want. I am using the API to create my projects.

When my project is in a state where it searches for all of the config files, and I look at the enabled features property when browsing to /api/deploymentprocesses/deploypmentprocess-Projects-#, I only see “ConfigurationTransforms” and not “VariableTransforms.”

Can you help me to configure my iis web application step so that Octopus doesn’t search for each config file?

Hi John,

Thanks for getting in touch,

I’m sorry to hear that this is causing inconvenience to you, hopefully I can be of assistance.

Based on the information provided in your query, my assumption is that the target files selected within the Configuration Transforms feature are highlighted in a generic fashion like *.config, as a result all files containing the .*config extension will be searched through as you highlighted.

In order to avoid searching through unnecessary files, you would need to specifically include the filename and extension within the target files as shown in my screenshot below;

You could include a variable within these area that resolves to a value based on the environment also, (i.e. web.#{Environment}.config} which changes to web.testing.config for the testing environment and web.uat.config for the UAT environment.

I hope this helps!

If you require any further assistance or clarification, please let me know :slight_smile:

Kind Regards,

Reece

Hi Reese. Thanks for your quick response.

I checked the Configuration Transforms section and I’m not using wild cards there. See the screenshot that I attached (Screenshot- Octopus Deploy - Configuration Transforms.png).

Based on the output from deployment (See screenshots of Deployment Output), it really seems like Octopus is acting as though the “Configuration variables” feature was enabled, though the checkbox is not checked. I’m seeing the phrase, “Variable replacement errors are suppressed because the variable Octopus.Action.Package.IgnoreVariableReplacementErrors has been set" (which I do set via the API for a workaround to this issue). Also, I keep seeing “No matching appSetting, applicationSetting, nor connectionString names were found…” Based on the help, I thought this is what “Configuration variables” feature looks for by default.

Keep in mind that I created these projects via the API and not with GUI. Also, my step that deploys the application is a child step. Is there any way for me to have unintentionally enabled the “Configuration variables” via the API and it’s not showing in the GUI?

Hi John,

Thanks for getting back to me,

/api/deploymentprocesses/deploymentprocess-Projects-ID will show each step and under Octopus.Action.EnabledFeatures it’ll show Octopus.Features.ConfigurationVariables, you can check to see if the Project has this feature enabled here.

Is it possible, however, that the release was created when the feature was enabled so the release snapshot contains this feature.

To look into this further, however, if you could provide the deployment log that would be greatly appreciated. I’ve included a link below to the docs area of our website for the associated log provisioning steps;

For your privacy, I’ve marked this conversation as a personal message.

I look forward to hearing back from you :slight_smile:

Kind Regards,

Reece

Hi Reece. Attached is the log file you requested.ServerTasks-7662.log-redact.txt (582.6 KB)

I took a look at the api/deploymentprocesses/deploymentprocess-projects-id, and couldn’t find the ConfigurationVariables setting under enabled features.

Regarding your release snapshot suggestion, I don’t know. Wouldn’t Octopus tell me to create a new release when my deployment doesn’t reflect the latest saved change? Also, the attached log shows that enabled features doesn’t contain the configuration variable feature yet it is acting as though that feature were enabled.

But…I can get Octopus to stop acting as though this feature were enabled by making a change to the “Deploy Application” step (any change), save it, and create a new release. The deployment for the new release will NOT act as though the configuration variable feature were enabled.

It’s as though my code (via the API) creates the Octopus projects in some bad state that only gets resolved when I make a change through the GUI. We have a lot of projects, so it would be tough to save each one through the GUI.

I ended up resolving this issue. I was setting “Octopus.Action.Package.AutomaticallyUpdateAppSettingsAndConnectionStrings” to true. Once I removed the setting through the API, everything worked as expected. Do you know why we can’t see this setting in the GUI? It would have made this issue easier to troubleshoot.

Thanks for the heads up on the log. I was able to find the setting by comparing the log with the issue to another log without the issue.

Thanks!

Hi John,

Thanks for getting back to me,

I’m glad to hear you were able to identify the root cause of this issue, I appreciate you letting me know the outcome.

I’m not sure why this setting isn’t visible via the GUI, however, I agree that this would have made troubleshooting significantly easier.

I’ll create a Github issue for this which I’ll link here so you’re able to keep up to date with the progress of this moving forward.

If you require any further assistance or clarification in the interim, please let me know :slight_smile:

Have a great day!

Kind Regards,

Reece

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.