gitlab_branch_protection fails when adding deploy_key_id to allowed_to_push

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Label this issue

I want to force users to create a merge request by preventing commits to the default branch. Only the CI pipeline should be allowed to do this with the help of a deploy key.

The command terragrunt plan produces the following output:

09:51:37.886 STDOUT terraform:   + resource "gitlab_branch_protection" "this" {
09:51:37.886 STDOUT terraform:       + allow_force_push             = false
09:51:37.886 STDOUT terraform:       + branch                       = "main"
09:51:37.886 STDOUT terraform:       + branch_protection_id         = (known after apply)
09:51:37.886 STDOUT terraform:       + code_owner_approval_required = false
09:51:37.886 STDOUT terraform:       + id                           = (known after apply)
09:51:37.886 STDOUT terraform:       + merge_access_level           = "maintainer"
09:51:37.886 STDOUT terraform:       + project                      = "516476"
09:51:37.886 STDOUT terraform:       + push_access_level            = "no one"
09:51:37.886 STDOUT terraform:       + unprotect_access_level       = "maintainer"
09:51:37.886 STDOUT terraform:       + allowed_to_push {
09:51:37.886 STDOUT terraform:           + access_level             = (known after apply)
09:51:37.886 STDOUT terraform:           + access_level_description = (known after apply)
09:51:37.886 STDOUT terraform:           + deploy_key_id            = 251200
09:51:37.886 STDOUT terraform:         }
09:51:37.887 STDOUT terraform:     }
09:51:37.887 STDOUT terraform: Plan: 1 to add, 0 to change, 0 to destroy.

The command terragrunt apply generates the following error message:

09:53:02.774 STDERR terraform: │ Error: Provider produced inconsistent result after apply
09:53:02.774 STDERR terraform: │
09:53:02.774 STDERR terraform: │ When applying changes to
09:53:02.774 STDERR terraform: │ module.branch_protection["terragrunt-gitlab-sico.main"].gitlab_branch_protection.this,
09:53:02.774 STDERR terraform: │ provider "provider[\"registry.terraform.io/gitlabhq/gitlab\"]" produced an
09:53:02.774 STDERR terraform: │ unexpected new value: .push_access_level: was cty.StringVal("no one"), but
09:53:02.774 STDERR terraform: │ now cty.StringVal("maintainer").
09:53:02.774 STDERR terraform: │
09:53:02.774 STDERR terraform: │ This is a bug in the provider, which should be reported in the provider's
09:53:02.774 STDERR terraform: │ own issue tracker.
09:53:02.774 STDERR terraform: ╵

As you can see, the value of push_access_level has been set to No One, but the deploy key has not been applied. I did that through the web interface to make sure that the CI pipeline is still working.

Running the command terragrunt plan again produces the following output:

09:54:10.798 STDOUT terraform: -/+ resource "gitlab_branch_protection" "this" {
09:54:10.798 STDOUT terraform:       ~ branch_protection_id         = 1403359 -> (known after apply)
09:54:10.798 STDOUT terraform:       ~ id                           = "516476:main" -> (known after apply)
09:54:10.798 STDOUT terraform:       ~ push_access_level            = "maintainer" -> "no one"
09:54:10.798 STDOUT terraform:         # (6 unchanged attributes hidden)
09:54:10.798 STDOUT terraform:       - allowed_to_push {
09:54:10.798 STDOUT terraform:           - access_level             = "maintainer" -> null
09:54:10.798 STDOUT terraform:           - access_level_description = "Deploy key used by CI job semantic" -> null
09:54:10.798 STDOUT terraform:           - deploy_key_id            = 251200 -> null
09:54:10.798 STDOUT terraform:         }
09:54:10.798 STDOUT terraform:       + allowed_to_push {
09:54:10.798 STDOUT terraform:           + access_level             = (known after apply)
09:54:10.798 STDOUT terraform:           + access_level_description = (known after apply)
09:54:10.798 STDOUT terraform:           + deploy_key_id            = 251200
09:54:10.799 STDOUT terraform:         }
09:54:10.799 STDOUT terraform:     }
09:54:10.799 STDOUT terraform: Plan: 1 to add, 0 to change, 1 to destroy.

I am not entirely show if this behaviour is caused by branch rules vs branch protection or the attributes access_level and access_level_description. At least these attributes are read-only in the current version of this Terraform provider.

The following code can be used to reproduce this issue:

module "gitlab_deploy_key" {
  source  = "gitlab.com/terraform-child-modules-48151/terraform-gitlab-deploy-key/local"
  version = "1.2.0"

  project = "example-group-48165/example-project"
  title   = "Example (deploy key)"
}

module "gitlab_group" {
  source  = "gitlab.com/terraform-child-modules-48151/terraform-gitlab-group/local"
  version = "1.2.0"

  name = "Example (group)"
  path = "example-group-48165"
}

module "gitlab_project" {
  source  = "gitlab.com/terraform-child-modules-48151/terraform-gitlab-project/local"
  version = "1.2.1"

  name = "example-project"

  description  = "Example (project)"
  namespace_id = module.gitlab_group.id
}

module "gitlab_branch_protection" {
  source  = "gitlab.com/terraform-child-modules-48151/terraform-gitlab-branch-protection/local"
  version = "1.0.1"

  branch  = "main"
  project = module.gitlab_project.id

  allowed_to_push = {
    deploy_key_id = module.gitlab_deploy_key.deploy_key_id
  }
  push_access_level = "no one"
}
``