gitlab_group_share_groupresources not detected when subgroup state is refreshed
- Troubleshooting Terraform state
When you are using the integration with Terraform and GitLab, you might experience issues you need to troubleshoot.
The GitLab Terraform provider can fail to detect existing
due to the issue “User with permissions cannot retrieve
share_with_groups from the API”.
This results in an error when running
terraform apply because Terraform attempts to recreate an
For example, consider the following group/subgroup configuration:
parent-group ├── subgroup-A └── subgroup-B
subgroup-Ais shared with
terraform-useris member of
owneraccess to both subgroups.
When the Terraform state is refreshed, the API query
GET /groups/:subgroup-A_id issued by the provider does not return the
subgroup-B in the
shared_with_groups array. This leads to the error.
To workaround this issue, make sure to apply one of the following conditions:
terraform-usercreates all subgroup resources.
- Grant Maintainer or Owner role to the
terraform-userinherited access to
subgroup-Bcontains at least one project.
On GitLab 14.2 and later, you might get a CI/CD syntax error when using the
latest Base Terraform template:
include: - template: Terraform/Base.latest.gitlab-ci.yml my-Terraform-job: extends: .init
The base template’s jobs were renamed with better Terraform-specific names. To resolve the syntax error, you can:
- Use the stable
Terraform/Base.gitlab-ci.ymltemplate, which has not changed.
Update your pipeline configuration to use the new job names in
https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Terraform/Base.latest.gitlab-ci.yml. For example:
include: - template: Terraform/Base.latest.gitlab-ci.yml my-Terraform-job: extends: .terraform:init # The updated name.
Unable to lock Terraform state files in CI jobs for
terraform apply using a plan created in a previous job
terraform init, Terraform persists these values inside the plan
cache file. This includes the
As a result, to create a plan and later use the same plan in another CI job, you might get the error
Error: Error acquiring the state lock errors when using
This happens because the value of
$CI_JOB_TOKEN is only valid for the duration of the current job.
By default, we set
If you don’t set
TF_ADDRESS in your job, the job fails with the error message
Error: "address": required field is not set.
To resolve this, ensure that either
TF_STATE_NAME is accessible in the
job that returned the error: