I have 4 environments defined: A, B, C and D. In my project i have limited the environment to A and B.
When i want to scope a variable in this project the environment list displays all the existing environment (A, B, C and D), shouldn’t it be filtered to only display environment assigned to the project?
I haven’t tested it but the role and machine list should also be filtered based on the machine in the project specified environments.
Thanks for getting in touch! This isn’t a bad idea. In fact this might be perfect for Life cycles: http://octopusdeploy.com/blog/lifecycles-rfc
As you will be able to determine all the Environments available to a project when choosing a life cycle, we can then restrict all variable scoping to those available environments.
it might be a little restrictive outside of this scenario as then we will be forcing steps to be created before being able to scope environments to variables, and some people might like creating their variables first.
Sorry i forgot to mention that i have filtered my environments at the project group level: project group A only uses environment A and B. So i would expect that any project in project group A only see environment A and B when scoping variable.
But as it seems that lifecycles will replace the environment scoping at the project group, it would be great to have this filtering of lists (environment, machine and roles) added to lifecycles
We are looking at the end of next month as a pre-release that will include life cycles. We have also added a note to make sure the variable scoping will exist within the life cycle domain for environments, machines and roles. Thanks for the excellent feedback.