continual changes detected due to changing etag

[StephenWithPH]

Terraform Version

Terraform v0.15.4
on linux_amd64
+ provider registry.terraform.io/integrations/github v4.9.4

Affected Resource(s)

• github_repository

Expected Behavior

After a successful terraform apply, subsequent terraform plan or terraform apply should detect no changes and have nothing to do.

Actual Behavior

Every terraform plan or terraform apply after creating the resource shows:

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply":

  # github_repository.foo has been changed
  ~ resource "github_repository" "foo" {
      ~ etag                   = <some value> -> <some other value>
        id                     = "foo"
        name                   = "foo"
        # (23 unchanged attributes hidden)
    }

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply to create a GitHub repo
2. terraform apply again and see the above warning regarding changes to etag

Important Factoids

Because etag is not exposed on the github_repository resource, it's not possible to mark it to be ignored.

[sdomula]

I ran into the same problem after upgrading to Terraform 0.15.4. Deleting the repositories from the state with terraform state rm and then importing them with terraform import did not solve this issue. The ETag is still reported to be changed outside of Terraform.

[mbainter]

JIC - I also experience this problem on 0.15.4 and integrations/github v4.10

[loozhengyuan]

I just encountered this after upgrading from 0.15.0 to 1.0.0. Interestingly, no changes were proposed even when Terraform detected a drift on the etag field:

$ terraform plan
Acquiring state lock. This may take a few moments...
...

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply":

  # github_repository.foo has been changed
  ~ resource "github_repository" "foo" {
      ~ etag                   = <some value> -> <some other value>
        id                     = "foo"
        name                   = "foo"
        # (23 unchanged attributes hidden)
    }

Unless you have made equivalent changes to your configuration, or ignored the relevant attributes using ignore_changes, the following plan may include actions to undo or
respond to these changes.

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

No changes. Your infrastructure matches the configuration.

Your configuration already matches the changes detected above. If you'd like to update the Terraform state to match, create and apply a refresh-only plan:
  terraform apply -refresh-only
Releasing state lock. This may take a few moments...

This behaviour seems consistent and expected as per the discussion on hashicorp/terraform#28803. As noted in the issue, using ignore_changes will not have an impact on this either.

I don't think there is much we can do at a provider-level to mitigate this, so I propose that we close this issue and track hashicorp/terraform#28803 in the upstream project.

[jcudit]

Thanks for surfacing this information 🙇🏾

Pretty concerning from a performance perspective, so open to more ideas and can prioritize fixes accordingly.

[ChristophShyper]

Ignoring this issue is not a good solution for many.
I'm running drift detection and it shows up all the time taking unnecessary time to investigate on each run.

[mbainter]

They're not really ignoring the issue - they're just pointing out that ultimately the provider is working as expected, and terraform isn't honoring it as an expected change that should simply be updated in state quietly -- so ultimately it's on hashicorp to fix this. (Because they're not even accepting PRs from the community right now)

[MOZGIII]

Why not just remove etag from the state? I mean, it is a possible solution at a provider level.

[jcudit]

It's value is passed through to the HTTP If-None-Match header when reading API resources, so good to store across Terraform runs. 🤔 maybe we could add a DiffSuppressFunc to the etag field if there are no objections to making the etag internals less transparent.

[loozhengyuan]

I think that the etag field is not particularly useful to end-users, so implementing DiffSuppressFunc should be a good approach to workaround this issue. Suppressing the etag field should not render changes to the other fields any less noticeable too.