separate resources for project creation and project settings

[genei09]

Feature Description

Currently it is possible to use data objects to look up all projects in a group and manage some settings / attributes such as MR approval rules. However it isn't possible to manage a vast majority of project settings this way as it requires importing existing projects to the state file.

Do you want to implement this?

• [ ] I would like to implement this myself 👷

[timofurrer]

@genei09 Thanks for the feature request!

However it isn't possible to manage a vast majority of project settings this way as it requires importing existing projects to the state file.

I suppose this is a "limitation" of how Terraform works in general: by taking ownership of certain resources and exclusively manage their lifecycle. Therefore, I'd question how much sense it would make to implement "something" which would attach to an existing project and manage its settings.

Would you have a concrete idea how that could look like in HCL? And how to clarify / solve the settings ownership between the existing gitlab_project and the "new resource" when there are conflicts?

[genei09]

The aws provider has some good examples of breaking apart the core creatable resource from additional configuration of it.

aws_vpc for example.

I can use data to look up a vpc and add tags to it, change the dhcp_options, and so on. There are several aws resources that also identify conflicting configuration within terraform. Like aws_security_group: "At this time you cannot use a Security Group with in-line rules in conjunction with any Security Group Rule resources. Doing so will cause a conflict of rule settings and will overwrite rules."

As such I think there is a precedence for having both and simply documenting the potential conflict if you specify the configuration in both resources.

Additional benefits: From a logical stand point, when you make a repo/project in gitlab you can't set the vast majority of these settings. You can specify an upstream, starting from a template, the namespace and name, as well as the description. It's a fairly small number of options. So this would allow the resource to more accurately match the manual steps a user would take to perform the same task.

By using data to lookup the project by name OR id you can also better ensure you are changing settings on the correct repo, and not risk destroying the entire repo while simply trying to manage the settings.

I currently have around 300 repos that I need to apply standard settings for. So there's considerable risk in importing each one and possibly to the wrong statefile. Much safer to simply manage the settings of all repos in a group from using data lookups.

[agjmills]

👍

[genei09]

As an additional case in point. The gitlab_project resource is the only place to set the default branch. However it's very difficult to set this at creation time if you aren't pulling from an existing repo. If I'm trying to start with an empty repo I need to create the repo, create the branches, then come back and change the code to include the default branch and do a second deployment. Makes it rather difficult for the code to be declarative