`initialize_with_readme` messes with project creation

[wr37ch]

GitLab Provider version

3.15.0

GitLab version

GitLab Enterprise Edition 14.9.1-ee

Terraform version

Terraform v1.2.1 on darwin_amd64

Relevant Terraform Configuration

resource "gitlab_project" "example" {
  name        = "example"
  description = "My awesome codebase"

  visibility_level       = "internal"
  namespace_id           = 9912
  default_branch         = "custom"
  initialize_with_readme = true
}

Relevant log output

gitlab_project.example: Creating...
╷
│ Error: Failed to create branch "custom" for project "4444": POST https://gitlab.internaldomain.com/api/v4/projects/4444/repository/branches: 400 {message: Branch already exists}
│ 
│   with gitlab_project.example,
│   on test.tf line 1, in resource "gitlab_project" "example":
│    1: resource "gitlab_project" "example" {
│ 
╵

Description

When I'm trying to create a project with some custom default_branch and initialize_with_readme = true I always get that Branch already exists error. The only time it works is if default_branch = "primary".

Interestingly enough, if I set initialize_with_readme = false, it will create any branch I specify and will put an empty README.md in it. Config example:

resource "gitlab_project" "example" {
  name        = "example"
  description = "My awesome codebase"

  visibility_level       = "internal"
  namespace_id           = 9912
  default_branch         = "development"
  initialize_with_readme = false
}

I'm confused and don't really get what's happening. Gitlab API says that default_branch requires initialize_with_readme to be true but it doesn't seem to be true with terraform provider.

[Shocktrooper]

I am actually experiencing the same issue I will link mine here for extra information and then close mine out as a duplicate of this one.

[Shocktrooper]

Not sure if this is an Upstream issue with the API or a problem with the way the provider used to handle default branches clashing with the current API but it appears that something has changed in the past few releases in GitLab to trigger this as it was a non-issue before

Start of Relevant provider code:

• https://github.com/gitlabhq/terraform-provider-gitlab/blob/main/internal/provider/resource_gitlab_project.go#L1021

[Shocktrooper]

This might result in another ticket but when trying the above suggestion to set initialize_with_readme = false and then set a default branch the project does get created as if the initialize with readme setting was set to true but when applying subsequent branch protection to said branch the following error occurs most likely because the default branch can be protected by default. What is equally interesting is this branch is protected in the first place even though the owning groups branch protection is off by default completely negating the workaround for default protected branches as noted in this comment here

Error: protected branch "prod" on project "197" already exists: {ID:176 Name:prod PushAccessLevels:[0xc000191f80] MergeAccessLevels:[0xc00061c000] UnprotectAccessLevels:[0xc00061c030] AllowForcePush:false CodeOwnerApprovalRequired:false}

[timofurrer]

@Shocktrooper Are you also testing against a 14.9 GitLab instance?

The reason why the code you've referred above even exists was because default_branch wasn't properly supported in the API. However, that should have been released with GitLab 14.10 (see milestone assignment in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63771).

Thus, for GitLab instances never then 14.9 this code shouldn't even be invoked.

What's strange though is that we still test against a GitLab 14.9 instance and we have a test for exactly that use case which works:

https://github.com/gitlabhq/terraform-provider-gitlab/blob/dbc86a65b8268761ee28211036a8e5b01a44b79f/internal/provider/resource_gitlab_project_test.go#L807

The only difference is that the project is created in a user and not group namespace (assuming that your namespace_id is indeed coming from a group 🤔

[Shocktrooper]

@timofurrer Its kind of funny that default_branch has been working as long as I can remember through the API. per #1123 I was using this with a 14.10 instance. The namespace_id is indeed from a group.

[timofurrer]

@Shocktrooper okay, interesting, can you work out a minimal reproducible example?

[Shocktrooper]

Its in #1123 but here it is here that trips up the fault

resource "gitlab_project" "project" {
  name                                             = var.NAME
  path                                             = replace(lower(var.NAME), " ", "-")
  description                                      = "123"
  namespace_id                                     = 123
  visibility_level                                 = "private"
  default_branch                                   = "prod"
  initialize_with_readme                           = true
}

Also note in my GitLab setup the the instance level default branch is set to dev and the project overrides it to prod

[timofurrer]

@Shocktrooper I've actually tried to reproduce the issue, but I'm not able to. Could you plug in your failing example into an acceptance tests on some branch?

[Shocktrooper]

Will do that later today 👍. Also another setting that might interact with it but I didn't think about it at first is my default branch protection on the group level is set to 0 for no protection and then I set the protection on a per project level per the workaround to set protected branches without terraform failures

[Shocktrooper]

@timofurrer Going to update my GitLab instance sometime this week and try the provider again.

I was not able to replicate the error on a CE GitPod instance of GitLab. I did however cause an import state verify error where I think it shouldn't be. Relevant settings are in the following branch.

https://github.com/Shocktrooper/terraform-provider-gitlab/tree/ReadmeTests

[Shocktrooper]

@wr37ch @timofurrer I have not ran into this issue as of 15.1 so with that being said I believe we can close this out if no one has any objections.

[wr37ch]

@Shocktrooper Yep, cannot see that issue with 3.16 on gitlab.com. Still see that on our on-prem 14.9.1-ee instance, even with v3.18. I guess this is also a part of the problem.

Thanks, we can close it.

[Shocktrooper]

@wr37ch Once you upgrade to 15.x it should be all good to go. That is when I saw my issues dissappear.