Hello,
I’m about to launch Octopus Deploy in our company.
I h ave a question regarding scoping of library variables. From the rest api, i can set project scoping to a library variable but it looks like it’s not supported from the user interface.
Is there a particular reason for this ?
In my use case it is important that a variable coming from a library variable is not available to a project if the dependency was not aproved in the first place.
To make it short, i use library variables to build a referential of our information system.
Then each, project represents the deployment of an application.
If the application was not granted access to the resource in the information system, the corresponding variable should not be available to the given project.
For this i need library variables scoping to projects.
As i see it, it’s something supported by the api but not by the user interface.
What should i trust ? api or user interface ?
If it is supposed to be suported, do you have plans to support porject scope for library variable from the user interface ?
Thanks for getting in touch! We do not support scoping library variables to projects. I couldn’t find a reference in our API wiki for scoping library variables to projects, the following link has a list of possible scoping for variable sets. https://github.com/OctopusDeploy/OctopusDeploy-Api/wiki/VariableScopeValues
There are currently no plans to support scoping library variables to projects, so adding a scope via the API should not work. Would you be able to attach a screenshot or the code you are using to do this?
From what i see in the OctopusClient assembly, it looks like there is an option to scope a variable to a project (first element in the enum definition) :
I’m not sure if the server implementation treats library variable sets and project variable sets in the same way but it would make sense that any variable can be scoped with same rules.
If the project scope should not be supported for variables coming from a library variable set, is this possible to use Action scoping instead ?
Thanks for getting back! Our library set variables and our project variables are handled differently by Octopus. Because of this, the same amount of scoping is not available between project and library variables. Library variable sets are added to projects on the project variable page as a whole, when we designed the library variable sets, we decided not to allow the individual scoping of their variables to projects, as the sets are (scoped) as a whole.
The available scoping for variable sets via the API, are in the wiki page I linked previously, scoping to an Action should work fine with library set variables.
Let me know if that helps, or if you have any further questions here.
Thanks for the clarification.
One more question, I can see how to set action scoping to a specific library set variable, but it looks like it’s not showing in the user interface.
Are there any plans to make this scoping information visible in the ui ?
Is the API the only way to configure such a scope ?
Thanks for getting back! So after some discussion with the team, we have decided that what you can see in the UI is the only scoping we support via API. It looks like we never configured our API to check here, so technically you can use the API to currently scope to things like Project, Action. As our Library Variable Sets are “Global” we only support the scoping of other global values, Environment, Roles, Targets, Tags.
I have created a GitHub issue to make the API scoping more inline with the UI here.
I am very sorry for any confusion that i have caused here in my previous response. While you technically can currently use the API to scope this, we have to advise against it, as it is not intended behavior.
Again, sorry for any confusion that I caused here.
Hello,
Being able to scope a variable in a library set to a project or action (but project would better suit my use case) is important to me.
If this is already implemented, why not expose it in the user interface instead of restricting the API ?
IMO it has great value to be able to be able to scope these variables to a project.
Reading my last response, I think I used the wrong words. The ability to scope these things via the API is not an oversight, but a bug.This behavior is not intended and not something we are able to support. Scoping to anything that is not listed in the UI will have unforeseen issues and is not something that the rest of Octopus has been designed to handle. The GitHub issue that I linked to was to disable the ability to scope these things via the API.
If you could provide some more details regarding your scenario and requirements here, I would be more than happy to try and find an alternative to scoping your library set variables to projects.
Looking forward to hearing from you. And again, I’m very sorry for not being clearer here.
I use library sets to build a referential of my information system. To illustrate my use case, let’s say that each variable as a value per environment.
Every application that participates to the information system has its own project/deployment pipeline and reuses variables defined in library sets (when it is deployed to a given environment, the variables are valued acordingly).
For exemple, let’s say i have a database i call OrderDatabase. In the library set i will create two variables per environment : OrderDatabase.Catalog and OrderDatabase.Server. (of course these two variables will have different values in each environment).
The advantage is that if two applicaitons need to access this database i can guarantee they point to the same catalog/server for a given environment.
All this works fine and is already implemented.
Now, i need to be able to restrict access to these variables on a per project basis.
If we take the previous exemple, i want to control the deployment projects that can see the OrderDatabase.Catalog and OrderDatabase.Server variables.
If the application declared the dependency over OrderDatabase and was granted the access, only then i want to allow the deployment project to use these two variables.
In my opinion these two things are complementary. Library sets help me to guarantee consistency of an environment, scoping helps me allowing/disallowing access to a resource.
Of course, the security is not based on the visibility of the variables. Even if the variable is visible and the project is deployed, the service account running the application won’t be able to use the database but it would be nice to reflect these restrictions in octopus as well.
I hope it’s more clear. Don’t hesitate if you need more informations.
Thanks for getting back. And thank you for the extra information. I understand what you are after here, yet unfortunately I do not have any work around for you. I think the best way to put it is that it comes down to the following. Library variables are global, projects are not. We do have a UserVoice suggestion which covers this, as it is something we get asked occasionally. In order for those variables to be seen only by people on that project, you will need to have them as project variables.
I think you have some good points for your desire to have this scoping available, or a system that will let you restrict access to certain library set variables. Leaving your thoughts on the UserVoice suggestion would be the best option here I believe
