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.

[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 hashicorp/terraform#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!

[kieran-lowe]

We also have this issue with the github_team resource. Constant etag differences which makes the plan file look horrible when reviewing.

[mkushakov]

Hello from 2024. Issue still present 😭

Terraform v1.7.3
on linux_amd64
+ provider registry.terraform.io/integrations/github v5.42.0

[mdemers-cobank]

We are also experiencing this issue using the latest terraform version and GitHub provider v6.0.0-rc2. :( We are using terraform to map our IdP groups in our GitHub Enterprise and this issue is causing lots of confusion and extended plan\apply times. Example Plan:

resource "github_emu_group_mapping" "group_mapping" {
~ etag = "W/"3f5366eca8e845a95699d17f7313f5366eca8e845a95699d17f7"" -> "W/"819796a827a942ee8f4fc08969481283b43819796a827a942ee8""
id = "teams/GitHub_TestTeam_Read/external-groups"
# (2 unchanged attributes hidden)
}

[mado-m]

I too am having trouble with the etag plan diff every time.
Is there any way to solve this?

  # github_membership.hoge has changed
! resource "github_membership" "hoge" {
!       etag                 = "W/\"6081217615376572602100717447281051506231251547763128376128640052\"" -> "W/\"2280374846717181661540412350875323550561580434460500625580837763\""
        id                   = "hogefugapiyo:hoge"
        # (3 unchanged attributes hidden)
    }

[oponomarov-tu]

We had somewhat related issue with github_team_sync_group_mapping resources, namely when the team_slug input has changed -- Terraform attempted to update the resource in-place and failed to do so. It continuously produced drift during subsequent terraform plan / terraform apply / terraform plan -target='<target>' runs.

The only way to get away from drift was to recreate the resource, but doing so in code was tricky -- we used terraform_data and replace_triggered_by to force it.

Before terraform_data & replace_triggered_by (see that the id wasn't reflecting new team name -- team-example-renamed-again, so was the etag):

  # module.github_team_default.github_team_sync_group_mapping.github_team_to_okta_group[0] will be updated in-place
  ~ resource "github_team_sync_group_mapping" "github_team_to_okta_group" {
        id        = "teams/team-example-renamed/team-sync/group-mappings"
        # (2 unchanged attributes hidden)

      - group {
          - group_description = "github sso: team-example-renamed - example description" -> null
          - group_id          = "<redacted>" -> null
          - group_name        = "app_github_team_example_renamed" -> null
        }
      + group {
          + group_description = "github sso: team-example-renamed-again - example description"
          + group_id          = "<redacted>"
          + group_name        = "app_github_team_example_renamed_again"
        }
    }

After terraform_data & replace_triggered_by:

resource "terraform_data" "replacement" {
  input = local.team_name
}

# configure github team to sync the membership from okta group
resource "github_team_sync_group_mapping" "github_team_to_okta_group" {
  count = local.create_github_team_sync_group_mapping ? 1 : 0

  team_slug = github_team.this[0].slug

  group {
    group_id          = okta_group.this[0].id
    group_name        = okta_group.this[0].name
    group_description = okta_group.this[0].description
  }

  lifecycle {
    replace_triggered_by = [
      terraform_data.replacement
    ]
  }
}

Output:

  # module.github_team_default.github_team_sync_group_mapping.github_team_to_okta_group[0] will be replaced due to changes in replace_triggered_by
-/+ resource "github_team_sync_group_mapping" "github_team_to_okta_group" {
      ~ etag      = "W/\"32a1b30bb70d6ab2531548xxxxxxxxxxxxx\"" -> (known after apply)
      ~ id        = "teams/team-example-renamed/team-sync/group-mappings" -> (known after apply)
        # (1 unchanged attribute hidden)

      - group {
          - group_description = "github sso: team-example-renamed - example description" -> null
          - group_id          = "<redacted>" -> null
          - group_name        = "app_github_team_example_renamed" -> null
        }
      + group {
          + group_description = "github sso: team-example-renamed-again - example description"
          + group_id          = "<redacted>"
          + group_name        = "app_github_team_example_renamed_again"
        }
    }

I'm not sure if this is the same issue, if so -- let me know, I'll create a separate bug report.

[dannysauer]

This is pretty annoying. If I add a lifecycle block to ignore changes to the etag and shar on a default branch, or etag and primary_language on the repo, I get warnings saying that's redundant.

The attribute primary_language is decided by the provider alone and therefore there can be no configured value to compare with. Including this attribute in ignore_changes has no effect. Remove the attribute from ignore_changes to quiet this warning.

But ignoring or not, Terraform emits a complaint that the parameter has changed:

  # module.repo_mldx.github_branch.default_branch has changed
  ~ resource "github_branch" "default_branch" {
      ~ etag          = "W/\"566fa4247b2de95d7e93c778b74fb695bbfc6bcdcc2f25c336a8ec6115c72606\"" -> "W/\"68fee6d98738cbe500cd289f986f4afa1cc195f1911ee0aa4234c6e62a08d1eb\""
        id            = "mldx:main"
      ~ sha           = "f0c11bfc820a39c912d9c4a23a65eea3eefebd22" -> "8ac2d53d20c849dab2ac82f9e0aa789448a28b29"
        # (5 unchanged attributes hidden)
    }

   # module.repo_mldx.github_repository.repo has changed
  ~ resource "github_repository" "repo" {
      ~ etag                        = "W/\"266fb252aedaca772a7ad8c8e5b721a098309ba79110899f510c5894bb54bb40\"" -> "W/\"ea9dce422a5fe96b65038c3f25a9c073b9b6240c526b601bd11d3463a352f196\""
        id                          = "mldx"
        name                        = "mldx"
      + primary_language            = "Go"
        # (34 unchanged attributes hidden)
    }

Is this something that can actually be fixed in the provider? I really don't need warnings that people are committing to a repo or the default branch after I create it, so I'd very much like to fix this.

[mdemers-cobank]

I don't know if this was a provider issue after all since the team members and group update value change constantly. We got around this issue for external groups by pulling out the group id from the object using locals:

locals {
team = {for key, val in data.github_external_groups.entraid_groups.external_groups :
key => val.group_id if lower(val.group_name) == lower(github_team.team.name)}

group_id = [for i, v in local.team : "${v}"]

group_output_id = tolist(local.group_id)[0]
}