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 https://github.com/hashicorp/terraform/issues/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 https://github.com/hashicorp/terraform/issues/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.

[jcudit]

The discussed change will go out in the next release. Please provide feedback on whether this helps as it was difficult to reproduce on my end.

[alexbde]

Looks like this change is not working, but causing issues: #910. Is there any other idea or do we need to hope for hashicorp/terraform#28803?

[danielvivasg]

Can you update on this? thanks!

[avgalani]

yep, also looking for an(y) update on this issue

[claytonpiccinin]

Same problem here. But in my case, I have an action that comment the result of plan in pull request comments. It causes a lot of noise and every time I try to update comments in pull request, the body is too large to comment.

This module is working as expected, but I think the noise can cause another problems in workflow steps as in my case.

[JustinYeoh93]

Same problem here. A workaround is that I just went with a -refresh=false approach and do sanity checks weekly with a cron GitHub Actions. Not the best but it does reduce the noise pollution

[jschwellnus92]

Also looking for an update on this - it is making our plan very noisy

[Csmithson-qh]

Also looking for some hope around this topic. i wouldn't go so far as to say this is making our plan "invalid" but as we are using a plan as a part of our PR process... having to tell people to "just ignore that little thing there" is going to be an issue....

[StephenWithPH]

https://github.com/hashicorp/terraform/releases/tag/v1.2.0 includes https://github.com/hashicorp/terraform/pull/30486. This may suppress the etag warnings we see.

Has anyone on this issue upgraded to v1.2.0 yet and seen same/different behavior regarding etag?

[morremeyer]

@StephenWithPH I upgraded over the weekend and run v4.25.0 of the github provider.

It is gone. The plan shows no diff.

So to everyone who still has this issue: Upgrade to terraform 1.2.0 (or later if you see this in the future) and you should be good.

Looks like this is resolved 🎉

[arslanbekov]

I confirm, on terraform 1.2.0 no problem and no etag changes.

[StephenWithPH]

@morremeyer @arslanbekov ... thank you for confirming.

Since the latest Terraform CLI suppresses the issue I raised on the GitHub provider, I'll close this issue.

[adziura-ledger]

I'm still having same issue. Even with TF 1.2.0 and Github provider 4.25.0 and higher. No etag changes when no changes or when using -target option. But if using standard plan - change in one team module generates a lot of useless output (etag changed)

[rpdelaney]

We are still affected by this. terraform v1.2.9 and github provider 5.1.0.

[ystndr]

Hi @kfcampbell, I understand that you're busy, but is there any plan to fix this issue?

I am aware that DiffSuppressFunc workaround has been reverted on #911.

I also might be able to help you reproduce the issue if you still haven't yet.

[kfcampbell]

@ystndr would you mind sharing an HCL snippet that reproduces the issue?

[alandreasyans]

@kfcampbell I can confirm that the issue still exists even in the newer versions. terraform --version Terraform v1.4.6 on linux_amd64 provider registry.terraform.io/integrations/github v5.24.0

[gabrielrinaldi]

Can we reopen this issue? Using Terraform Drift detection this causes a lot of false warnings.

[kfcampbell]

Sure, I've reopened the issue. PRs are always appreciated!

[frankpengau]

Experiencing same etag attribute diff issue in tf plan, anything in the near future roadmap to fix this?

Getting this for resource "github_repository"

[kfcampbell]

Unfortunately the SDK team at GitHub does not currently have the bandwidth to do feature development on existing SDKs at the moment. PRs are always appreciated though!