After reading this support doc, I have created a Variable Set “Octopus Debug Output” with two variables: (1)OctopusPrintEvaluatedVariables and (2)OctopusPrintVariables
I set a default value of ‘False’ for each variable, and define another value of ‘True’ scoped to something specific; an environment, role, or target (or any combination of).
In the context of a new release and deployment of a project that does not fall under the ‘True’ value’s scope, but has had the variable set included, the following is witnessed:
Variable Preview indicates that the two variables will evaluate to false
Reviewing the evaluated variables for the release using “Variable Snapshot” presents values aligned with Variable Preview; false
Reviewing Task Log for the release deployment shows warnings that the two variables are enabled.
It appears as though any truthy value present in the Variable Set, regardless of applicable scope, causes the functionality of the logging to differ from use cases where scope is necessary to evaluate a variable where it should not.
Thank you for your email and bringing this to our attention.
I replicated the steps you have listed above on the latest version of Octopus Server (2019.10.1) to reproduce variables being written to the deployment log but have been unsuccessful.
Can I please ask, which version of Octopus Server are you using? Would you be able to attach some screenshots of the Deployment log and your variable editor screen please?
Thanks for your reply and apologies for the delay on getting back to you with this.
How did you go with your upgrade? Did it resolve your issue? I tried recreating the error on 2019.6.8 LTS but wasn’t able to. Are you using hosted or on-prem version of Octopus Server? Any screenshots you could send us would be useful for us to get to the bottom of this bug.
The project for which this deployment was run was not in the filtering rule in which True is the applied value for either variable. In fact, this is occurring in the Targets specified to be false by both rules 1 and 3 for each variable.
As you can see, it does not seem like the same determination of variable value is used for the snapshot and the logging. For our purposes, this is an annoyance because the warning ‘!’ deployment status icon draws attention. This behavior has not been seen in non special/system variables that are global such as these debug ones.
Thank you for your reply and apologies that you are still facing this issue!
I had another go at it and I believe I have been able to recreate your scenario locally. I would like to point out a couple of things for more context. You can perceive the different scopes (environments, roles, deployment targets) are joined together by “ANDs” and the items within each category are chained using “ORs”. Also, higher specificity indicates higher priority.
In my set-up, I have a Development environment and Role A and Role B scoped to False but have Tentacle A and Tentacle B (which belong to Role A and Role B respectively) scoped to True.
Here, the deployment targets Tentacle A and Tentacle B are more specific than Role A and Role B. Hence, the value True takes precedence for those deployment targets and the variables are displayed.
Hope that makes things a little bit more clearer! I would suggest reducing the specificity in the scoping where those print variables are set to True. Please let me know if you run into any more issues with this.
I do not believe your example is representative of the issue captured in my screen shots. On the face, it has split-level contradicting rules that require knowledge of the internal hierarchy and scope-scoring (css-like) to work out. That intricate evaluation has not been necessary in our setup of templated target-diverse stratified application deployments (everything else we are making use of in Octopus). Additionally, our rule for these variables is much simpler- off everywhere except the one super-specific scope. Everything else shown was an attempt to strengthen the filtering of scope when the basic approach did not work. Our goal was to have just the Development Deployment for a project with the verbose logging enabled to examine the deployment activity as it is being onboarded to our CI/CD Pipeline or should an issue arise.
As I mentioned, my initial approach was based on the OP’d reference article at the time: Variables to set the Print Variables to False (no scope), with the Environment (Development) / Role (deployment of an application represented by an Octopus Project) / Target (deployment server).
If false is the default, does it follow given your recommendation that we could achieve our goal by simply having one variable (for each type of print variable) specific to just one Environment + Role + Target, and have no mentions of the print enablement in any of our application deployments?
As it stands, we are avoiding the use of this feature or leaving maintenance mode on to avoid distracting developers with false positives on deployment warnings. This feature does not behave like the scope determination for variables which we have established and have a healthy templated implementation for.
If false is the default, does it follow given your recommendation that we could achieve our goal by simply having one variable (for each type of print variable) specific to just one Environment + Role + Target, and have no mentions of the print enablement in any of our application deployments?
Yes, that is correct. False is default and you don’t need to set it explicitly. You only need the one True case. You don’t need to mention the print enablement in any of your application deployments.
