Add project setting ci_pipeline_variables_minimum_override_role #2057
Conversation
This is a companion setting to `restrict_user_defined_variables`, allowing more granular control over who can set job variables and pipeline variables in a project. Currently, the setting `restrict_user_defined_variables` acts as a toggle for the restriction set by `ci_pipeline_variables_minimum_override_role`, but it is likely that `restrict_user_defined_variable` will be deprecated in favor of just `ci_pipeline_variables_minimum_override_role` in the future. See https://docs.gitlab.com/ee/ci/variables/#restrict-who-can-override-variables
projects.go
Outdated
| @@ -157,6 +157,7 @@ type Project struct { | |||
| MergePipelinesEnabled bool `json:"merge_pipelines_enabled"` | |||
| MergeTrainsEnabled bool `json:"merge_trains_enabled"` | |||
| RestrictUserDefinedVariables bool `json:"restrict_user_defined_variables"` | |||
| CIPipelineVariablesMinimumOverrideRole AccessControlValue `json:"ci_pipeline_variables_minimum_override_role"` | |||
There was a problem hiding this comment.
I chose AccessControlValue to match existing code, but for what it's worth, the AccessControlValue type seems to have been originally intended for something completely different. Over time, it seems to have morphed into more of a catch-all string type for different access control values 🤷
There was a problem hiding this comment.
@vindvaki - I agree, I'm not sure AccessControlValue is the right type here. Since the API seems like it's accepting a string value for the Access Level instead of the integer value (which is usually defined using the AccessLevelValue type), I think we should probably create a new type for it in types.go, especially since no_one_allowed seems to deviate from the normal no_one that's used elsewhere.
would you mind doing that? Otherwise this LGTM!
There was a problem hiding this comment.
@RicePatrick sure, I've created a new type in fc7656e. Let me know what you think 🏓
There was a problem hiding this comment.
@vindvaki - I apologize for nitpicking, but would you mind adding a comment on the new type to match the values of the others within the file? I tried to push a commit for you, but I don't have permissions to do so :)
I'd suggest something like this:
// CIPipelineVariablesMinimumOverrideRoleValue represents an access control
// value used for managing access to the CI Pipeline Variable Override feature.
//
// GitLab API docs: https://docs.gitlab.com/ee/api/projects.html
type CIPipelineVariablesMinimumOverrideRoleValue = string
// List of available CIPipelineVariablesMinimumOverrideRoleValue levels.
//
// GitLab API docs: https://docs.gitlab.com/ee/api/projects.html
const (
CIPipelineVariables_NoOneAllowedRole CIPipelineVariablesMinimumOverrideRoleValue = "no_one_allowed"
CiPipelineVariables_OwnerRole CIPipelineVariablesMinimumOverrideRoleValue = "owner"
CiPipelineVariables_MaintainerRole CIPipelineVariablesMinimumOverrideRoleValue = "maintainer"
CIPipelineVariables_DeveloperRole CIPipelineVariablesMinimumOverrideRoleValue = "developer"
)There was a problem hiding this comment.
@RicePatrick thanks, done 🏓
|
@timofurrer @RicePatrick looks like you are the new maintainers? Could either of you please review? Thanks! |
|
@vindvaki - Yep, I'll probably get to it tomorrow; thanks for the ping! |
|
Approved the GitHub workflows, and one last nitpick then this LGTM! |
There was a problem hiding this comment.
@vindvaki sorry for another nitpick. I'm trying to apply myself and merge.
|
@vindvaki @RicePatrick I'm going to merge here. Thanks Hordur! I assume you need a release? |
This is a companion setting to
restrict_user_defined_variables, allowing more granular control over who can set job variables and pipeline variables in a project. Currently, the settingrestrict_user_defined_variablesacts as a toggle for the restriction set byci_pipeline_variables_minimum_override_role, but it is likely thatrestrict_user_defined_variablewill be deprecated in favor of justci_pipeline_variables_minimum_override_rolein the future.See https://docs.gitlab.com/ee/ci/variables/#restrict-who-can-override-variables