Hi Canny,
Thanks for the examples. The problem that Nick described is that if one of those variables was referenced by another variable, it does essentially allow a ‘Developer’ to override a ‘Production’ scoped variable. For example, lets take these variables:
Name: ShareRoot, Value: \NetworkShareDEV, Environment: DEV, Step: non-scoped
Name: ShareRoot, Value: \NetworkShareSIT, Environment: SIT, Step: non-scoped
Name: ShareRoot, Value: \NetworkShareUAT, Environment: UAT, Step: non-scoped
Name: ShareRoot, Value: \NetworkSharePROD, Environment: PROD, Step: non-scoped
Now, suppose that you use the ‘Custom installation directory’ feature in Octopus to have the files copied to your file share. You want to vary it by environment, so you bind the value:
#{ShareRoot}
Internally, we have a variable that looks like this:
Octopus.Action.Package.CustomInstallationDirectory = #{ShareRoot}
This is a system-defined variable that we set based on what you bind in the UI.
Now, the developer can’t edit the value of ShareRoot
, but they CAN create a new, unscoped variable:
Octopus.Action.Package.CustomInstallationDirectory = \NetworkSharePROD (unscoped)
This isn’t just a problem with the way we manage variables internally, but any time you bind a variable. For example, if you had this:
ConnectionString = Server=#{SqlServer};Database=OurDB;trusted_connection=true
SqlServer = SQLPROD01 (scope: Production)
SqlServer = SQLUAT01 (scope: UAT)
A bad developer could just edit the un-scoped variable:
ConnectionString = Server=SQLProd01; (unscoped)
Hopefully you can see why this is a problem, and why we decided not to allow editing of unscoped variables.
However, I do see the practical aspects of what you described. Besides, changes to variables are audited, so if someone does try to work around the system you’ll at least be able to work out who. So we’re going to do this in 2.4 - not by default, but by giving you the ability to edit/define your own roles, and to add a special “edit non-environment scoped variables” permission to your custom role.
Hope that helps to explain why we we’re reluctant to do this initially.
Paul