gitlab_project_access_token: Provider produced inconsistent final plan
Bug Report
When applying a plan which rotates tokens, it fails with an inconsistent plan. Interestingly, it does work, if a new plan is created and applied afterwards. So probably related to something with the time provider again.
╷
│ Error: Provider produced inconsistent final plan
│
│ When expanding the plan for gitlab_project_access_token.token to
│ include new values learned so far during apply, provider
│ "registry.terraform.io/gitlabhq/gitlab" produced an invalid new value for
│ .id: was known, but now unknown.
│
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
╵
Relevant Terraform Configuration
terraform {
required_providers {
gitlab = {
source = "gitlabhq/gitlab"
version = "17.1.0"
}
}
}
variable "gitlab_token" {
type = string
sensitive = true
}
provider "gitlab" {
token = var.gitlab_token
base_url = "https://gitlab.com/api/v4"
}
resource "time_offset" "year" {
offset_days = 364
}
resource "gitlab_project_access_token" "token" {
project = 58586280
name = "token"
expires_at = split("T", time_offset.year.rfc3339)[0]
access_level = "developer"
scopes = ["read_api"]
}
Relevant Terraform Command
terraform init
terraform apply --auto-approve
# change the offset_days in time_offset.year to something that will cause a rotation of the token or wait for the next day :D
terraform taint time_offset.year # this could also be triggered by using a time_rotating resource
TF_LOG_PATH=$(pwd)/log.jsonl TF_LOG=JSON terraform apply --auto-approve # this fails
Relevant Log Output
I have gone over the output for more than 2 hours now, it should not contain anything sensitive, but putting it in an internal note anyways to be safe.
These are the debug logs of the `terraform` command output:
Provided in internal note
Additional Details
- GitLab Terraform Provider Version:
17.1.0
- GitLab Version:
17.2.0-pre 08b8dd794bf
(.com) - Terraform Version:
1.5.7