I disagree that by default a variable set should apply to all projects - I'd say it would be better to grant less permissions until needed/wanted (and that these have to be explicitly added... rather than added by default).
I DO agree with the idea that variable sets should be able to be linked with only specific/selected pipelines. For example...
At present, sensitive variables added to a variable set are immediately available to ALL pipelines/projects. That means that if you use a username and password (for example) within one variable set, then anyone else with access to the variable set (i.e. all pipelines, by default) is able to use that username and password to do what they want.
At present, in Octopus, you can limit access to the pipelines/projects (and related groups), but the variable sets are effectively global and there is no access control on these at present (other than maybe to amend/update them).
You'd also have to ensure that there were distinct roles/permissions available (for example):
- Users that could update variable sets (possibly specific to the variable set? and/or the environment within the variable set?)
- Users that could link the variable set to a project/pipeline or project group
The same items may apply for 'Accounts' (under 'Infrastructure')... you can limit an account being used within an environment, but that account can be used in any project within Octopus (that scope/access is too wide (in my opinion).
We like this idea too.
Agreed. Similar requirement to my comment here..
I would also say that this is applicable to step templates and libray, variable sets.
In my view, it would be nice to be able to setup a set of "required variables" as part of (or in a similar way to) library sets so:
- A user can define a variable set (including "required variables") which are available in the library. These "required variables" may have a default value (fixed or derived from another variable) or no value. There would also the option to setup these variables with a fixed/allowed/dropdown of values that can be selected/used.
- When a variable set (from the library) gets added into the Project Variables, these "required variables" are added in a virtual/non-permanent manner. These may be changed (they are not fixed like variables in a standard variable set) but the team member updating the project is then aware they need to provide those values.
Also, related to this, it would be useful to be able to set library variable sets (including "required variable" sets) as "depended upon" by other variable sets and step templates. This would allow cascading/nested variables to be managed more strictly (ensuring consistency) and would allow variables to be setup in a project as "required" if they were needed by a step template.
Agreed, but I'd take it a few steps further...
Currently, Octopus pipeline steps (and step templates) take the packages from the composite/proxy Octopus Nuget/package feed (made up of the Octopus feed/repo and any external feeds setup within Octopus).
Certain packages may only be relevant to particular pipelines so having visibility of all packages in every pipeline seems excessive, and there is also the risk that by pushing to the Octopus repos (or one of the external feeds/repos), packages can be accidentally or maliciously pushed to replacing valid/correct versions with incorrect/malicious ones of the same name/ID (but higher verison, for example)... thus increasing the chance/risk of problems occuring as a result of these incorrect packages.
Steps and Step Templates that use/select packages could, in theory be limited to packages located within...
- All feeds (i.e. Octopus feed and all external ones)
- Selected feeds, limited by one or more of:
- Project Group
If feeds are being managed outside of Octopus (i.e. in an external NuGet repostory manager/server, but split into multiple, segregated feeds), then it would be useful to be able to still be able to keep these feeds seperated within the use of Octopus so user permissions/access can remain segregated.
Added to this thread/suggestion...