Discussion: How could we leverage the new cascading setting option?
devopsmanage release a new cascading setting option
- documentation
- Enforce instance and namespace level merge method
- Cascading Setting for Delayed Project Deletion
You can set, at the namespace level, an option to enforce a setting against all subgroups
it's currently new and so as an MVC it's obviously not granular
But i wonder if we could work toward utilizing this as a tool to allow customers to enforce a license policy across a namespace, or is this the wrong mechanism?
we would of course need to work with manage in the future to iterate this tool to allow different policies to be set for different groups/sub-groups
target of the discussion is for license policy - which today we store per project - we'd need to get permission to move the policy into ??? in order to be available at the namespace level
Known issues
- we could apply the policy but if license scanning is not enabled, nothing will apply the policy (ideally we could warn / query for this? possible blocker - getting enabled into a database so queryable otherwise flaky if reliant on last pipeline ran)
- we could apply the policy but they have no MR approver group setup so builds get blocked with no possible approvers (ideally we could warn / query for this?)
Questions
- are there any plans for merge request approvers to get up to group / sub-group levels? or allow setup of a mr approver group and have it bulk add to all projects in a group / sub-group / namespace?
- do we think this would solve our need better or faster than groupcompliance tagging (i.e. we were looking at if something had tag X enforce rule Y)?
- Do we think this would solve our need better or faster than ~"Category:Security Orchestration" (i.e. where you can set simplistic if this then this rules)?
- do we feel like we should work to move all 3 items closer into alignment for eventual merging?