gitlab_group_variable unable to update value of previously applied key

[Liberis]

Terraform Version

Terraform v1.1.5

Affected Resource(s)

resource "gitlab_group_variable"

Terraform Configuration Files

resource "gitlab_group_variable" "group_variable" {
  for_each          = local.gitlab_variables
  group             = var.group_id
  key               = each.key
  value             = each.value
  protected         = true
  masked            = false
  environment_scope = var.env_value
}

Expected Behavior

What should have happened? Ability to update gitlab group variable with the same name.

Actual Behavior

What actually happened? terraform apply failed with the following error: Error: PUT https://gitlab.com/api/v4/groups/*******/variables/var_name: 400 {message: {key: [(var_name) has already been taken]}} │ │ with gitlab_group_variable.group_variable["group_var"], │ on main.tf line 32, in resource "gitlab_group_variable" "group_variable": │ 32: resource "gitlab_group_variable" "group_variable" { |

Steps to Reproduce

1. Create a gitlab group variable with a fixed name.
2. terraform apply to create the variable on gitlab group.
3. Change the variable value to something else.
4. Reapply

[timofurrer]

Does this also happen for you without the for_each, basically for a single group variable?

[Liberis]

I can confirm that the behavior does not appear in a single group variable. Only when using for_each.

Regards,

Liberis

[timofurrer]

Okay, I'll dig into that later ... Out of curiosity: does it also happen without the environment scoping?

On Thu, Feb 10, 2022, 6:15 PM Liberis @.***> wrote:

I can confirm that the behavior does not appear in a single group variable. Only when using for_each.

Regards,

Liberis

— Reply to this email directly, view it on GitHub https://github.com/gitlabhq/terraform-provider-gitlab/issues/861#issuecomment-1035187557, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHWE7ABMZEJJXGROOM6DCDU2PXBZANCNFSM5OBH7AJA . You are receiving this because you commented.Message ID: @.***>

[Liberis]

It seems that if the environment scope is specified gitlab api cannot update the variable.

Also replicated using the api : curl --request POST --header "PRIVATE-TOKEN: <your_access_token>"
"https://gitlab.example.com/api/v4/groups/1/variables/NEW_VARIABLE" --form "value=value" --form "environment-scope=env"

curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>"
"https://gitlab.example.com/api/v4/groups/1/variables/NEW_VARIABLE" --form "value=updated_value" --form "environment-scope=env"

[timofurrer]

@Liberis I'm still unable to reproduce this. What responses do you get from the API calls you posted.

Creating a simple non-protected / non-masked variable with an environment scope:

curl -X POST http://localhost:8080/api/v4/groups/108/variables --header "PRIVATE-TOKEN: ACCTEST1234567890123" --form "key=some_var" --form "value=some_value" --form "environment_scope=env" | jq
{
  "variable_type": "env_var",
  "key": "some_var",
  "value": "some_value",
  "protected": false,
  "masked": false,
  "environment_scope": "env"
}


curl -X PUT http://localhost:8080/api/v4/groups/108/variables/some_var --header "PRIVATE-TOKEN: ACCTEST1234567890123" --form "value=some_other_value" --form "environment_scope=env" | jq
{
  "variable_type": "env_var",
  "key": "some_var",
  "value": "some_other_value",
  "protected": false,
  "masked": false,
  "environment_scope": "env"
}

Creating a simple protected / non-masked variable with an environment scope (as you do):

curl -X POST http://localhost:8080/api/v4/groups/108/variables --header "PRIVATE-TOKEN: ACCTEST1234567890123" --form "key=some_protected_var" --form "value=some_value" --form "environment_scope=env" --form "protected=true" | jq
{
  "variable_type": "env_var",
  "key": "some_protected_var",
  "value": "some_value",
  "protected": true,
  "masked": false,
  "environment_scope": "env"
}


curl -X PUT http://localhost:8080/api/v4/groups/108/variables/some_protected_var --header "PRIVATE-TOKEN: ACCTEST1234567890123" --form "value=some_other_value" --form "environment_scope=env" | jq

{
  "variable_type": "env_var",
  "key": "some_protected_var",
  "value": "some_other_value",
  "protected": true,
  "masked": false,
  "environment_scope": "env"
}

[timofurrer]

Alright, I can reproduce if two environments have the same variable - you can actually create them, but not update.

Just to confirm? Do you have variables with the same key for multiple environments?

[timofurrer]

Properly setting the filter in the PUT call, helps, e.g.:

curl -g -X PUT "http://localhost:8080/api/v4/groups/108/variables/some_protected_var?filter[environment_scope]=env" --header "PRIVATE-TOKEN: ACCTEST1234567890123" --form "value=blabla"

[timofurrer]

I see, @Liberis ... can you please try and use the latest provider version >= 3.9.0 ?

Support for the environment scope for gitlab_group_variables has been added in https://github.com/gitlabhq/terraform-provider-gitlab/releases/tag/v3.9.0 (see #717)

[Liberis]

Alright, I can reproduce if two environments have the same variable - you can actually create them, but not update.

Just to confirm? Do you have variables with the same key for multiple environments?

@timofurrer Yes I am using variables with the same key for multiple environments.

The error occurred in provider version 3.9.0

[timofurrer]

I can reproduce it now, thanks for the report - I'll get back to you.

There are definitely some interesting issues open in go-gitlab:

• https://github.com/xanzy/go-gitlab/issues/746

[timofurrer]

After some debugging it seems to be an upstream issue: https://gitlab.com/gitlab-org/gitlab/-/issues/333296

I'm afraid we can't do much here.

[nagyv]

@Liberis @timofurrer As GitLab already triaged this issue as relatively low severity and priority, I don't expect GitLab engineers to have time to fix it. As a result, I see two options:

• If you have a GitLab subscription, please, reach out to GitLab support or your TAM to highlight your interest in the issue being fixed.
• As the issue is marked as "Accepting merge requests", I would like to encourage you to try contributing the fix to GitLab.

[Liberis]

Following up the guidelines provided by Nico I will also try to catch up. I will keep you posted with any findings and/or progress.