google_artifact_registry_repository churn with maven_config

[andrew-stephens-insight]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.
• If an issue is assigned to the modular-magician user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

Terraform v1.4.6

Affected Resource(s)

• google_artifact_registry_repository

Terraform Configuration Files

# used to prevent name collisions
resource "random_id" "repo_suffix" {
  byte_length = 3
}

resource "google_artifact_registry_repository" "repo" {

  project       = var.project_id
  repository_id = format("%s-%s", "test-maven-repo", random_id.repo_suffix.hex)
  format        = "MAVEN"
  location      = "us"
  description   = "Test Maven Repository"

  maven_config {
      version_policy            = "VERSION_POLICY_UNSPECIFIED"
      allow_snapshot_overwrites = false
  }
}

Debug Output

Panic Output

Expected Behavior

Running a second plan or apply after initial successful apply should show no changes.

Actual Behavior

Plan shows the Maven repository will be destroyed and re-created even though no code changes.
The maven_config block shows that both variables are being set again, forcing replacement.

• maven_config {
  + allow_snapshot_overwrites = false # forces replacement
  + version_policy = "VERSION_POLICY_UNSPECIFIED" # forces replacement
  }

I checked the TFState. The maven_config block is not being saved in the state.

Steps to Reproduce

1. terraform apply
2. terraform plan

Note: I tried this with the google and google-beta providers.

Important Factoids

References

• #0000

[edwardmedia]

@andrew-stephens-insight can you share your debug log that contains the request and response to the api?

[edwardmedia]

b/287234450

[andrew-stephens-insight]

@edwardmedia , I will add that later today. It's similar to #14846, but in this case it's producing destroy and re-create instead of just churn.

[Subserial]

I believe this PR has addressed the bug.

[zchenyu]

Has this been released yet? The latest version is 5.0.0 and I'm still seeing issues.

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # google_artifact_registry_repository.xxxxx will be updated in-place
  ~ resource "google_artifact_registry_repository" "xxxxx" {
        id               = "projects/xxxxx/locations/us-west1/repositories/xxxxx"
        name             = "xxxxx"
        # (10 unchanged attributes hidden)

      - maven_config {
          - allow_snapshot_overwrites = false -> null
          - version_policy            = "VERSION_POLICY_UNSPECIFIED" -> null
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

google_artifact_registry_repository.xxxxx: Modifying... [id=projects/xxxxx/locations/us-west1/repositories/xxxxx]
╷
│ Error: Error updating Repository "projects/xxxxx/locations/us-west1/repositories/xxxxx": googleapi: Error 400: Maven config is not supported for format "DOCKER"
│ 
│   with google_artifact_registry_repository.xxxxx,
│   on artifact_registry.tf line 1, in resource "google_artifact_registry_repository" "xxxxx":
│    1: resource "google_artifact_registry_repository" "xxxxx" {

[Subserial]

Ah, this is an issue a few others have mentioned, independent from Terraform. If you are able to recreate the repository then this will be fixed, but in the meantime we are working on manually removing this field from existing Docker repositories.

[eyalzek]

@Subserial could you provide more info as to why this issue was/is happening? Was there a time that a maven_config was added to all AR repos?

What change to the API/provider caused it to start forcing recreation of resources?

You're saying that it's independent of TF, could you say what's the source of it?

[Subserial]

Sorry for the long delay. Yes, affected repositories had a maven_config field even if they weren't Maven repositories. We manually removed that field from Docker repositories, and the API should prevent new repositories from falling into that state.

[melinath]

Marking as resolved per #14900 (comment)

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.