This impacts users expectations. As a user I should be well informed - for example when someone from my team change configuration and understood whats going on. Is there any chance to restore this information ?
Thanks for reaching out, and for the great question.
You’re correct that the warning was removed as part of the Issue linked above, and I apologize if this has caused unexpected headaches with your deployment processes. I’ll funnel your feedback through to the product team who made this change as a data point, and to see if any other workarounds are in the pipeline to help alleviate this situation, and make this information more visible.
I’ll circle back around with you when I have any updates on this.
Hi @Justin_Walsh,
thanks for your support and understanding of the situation.
I wonder if you have any new news for me. Maybe this warning will not come back, but another better approach will be implemented, that will be used to indicate configuration drift in release page.
A delayed reply I know, but we’ve just been discussing this issue and we’re hoping you might be able to help us.
We’re looking at options to re-implement the removed information, but we think there’s something deeper. Could you share any extra context around the type of variables that you are interested in knowing have changed since a release was created? What do they represent?
Specifically, we’re pondering if it would help if we provided an option for some variables to not be snap-shotted with a release. As an example, if you have a variable representing credentials, or infrastructure, any time this changes one probably wants the current value, not the value at the time of release creation.
Essentially we’re wondering if the root reason that people are interested if variables have changed, is because they always want the current value.
I try to answer you question to the best I can.
We are interested if variables have changed, because we want follow the changes and guarantee a pace of mind, when we press deploy button. We need a simple control, fetch changes or ignore them. Previous information helped us to recognize changes and simply force to think about them. Current variable comparison is not very useful in Octopus, but that warning could stop us from making incidents and discuss change with person/team if make a change (for example in Variable Set) once again. Some non snap-shotted variables with a release should be a option, but not a breking change.
We look forward to hearing about the new idea.
Best regards
Piotr