Editing github_actions_secret from TF apply fails

[kmeinster]

Terraform version: v0.14.10

Resource(s):

* github_actions_secret
* (maybe) github_actions_organization_secret

resource "github_actions_secret" "this" {
  plaintext_value = data.sops_file.secret-configs.data["repositories.secret-example.secret_name"]
  repository = "secret-example"
  secret_name = "MY_SECRET"
}

2021-06-04T12:34:37.340+0200 [DEBUG] plugin.terraform-provider-github: 2021/06/04 12:34:37 [DEBUG] The value of github updated_at: 2021-06-04 10:34:12 +0000 UTC ; the value of state updated_at: 2021-06-04 10:34:36 +0000 UTC ; the value of ok: true

2021-06-04T12:34:37.340+0200 [DEBUG] plugin.terraform-provider-github: 2021/06/04 12:34:37 [WARN] The secret secret-example:MY_SECRET has been externally updated in GitHub

2021/06/04 12:34:37 [DEBUG] github_actions_secret.this: apply errored, but we're indicating that via the Error pointer rather than returning it: Provider produced inconsistent result after apply: When applying changes to github_actions_secret.this, provider "registry.terraform.io/integrations/github" produced an unexpected new value: Root resource was present, but now absent.

Behavior

When creating the secret from scratch (as in the secret doesn't exist yet) the resource gets created fine. However when updating the resource it seems that

terraform-provider-github/github/resource_github_actions_secret.go

Lines 111 to 133 in b2f41b2

	// This is a drift detection mechanism based on timestamps.
	//
	// If we do not currently store the "updated_at" field, it means we've only
	// just created the resource and the value is most likely what we want it to
	// be.
	//
	// If the resource is changed externally in the meantime then reading back
	// the last update timestamp will return a result different than the
	// timestamp we've persisted in the state. In that case, we can no longer
	// trust that the value (which we don't see) is equal to what we've declared
	// previously.
	//
	// The only solution to enforce consistency between is to mark the resource
	// as deleted (unset the ID) in order to fix potential drift by recreating
	// the resource.
	if updatedAt, ok := d.GetOk("updated_at"); ok && updatedAt != secret.UpdatedAt.String() {
	log.Printf("[WARN] The secret %s has been externally updated in GitHub", d.Id())
	d.SetId("")
	} else if !ok {
	d.Set("updated_at", secret.UpdatedAt.String())
	}
	return nil

kicks in, resulting in the messages above and another apply is needed to actually apply the change.

The secret was not changed outside Terraform.

When doing the initial terraform apply to change the secret, terraform will try to do a change that one will fail, executing the second time will result in terraform wanting to add the secret which will succeed.

steps to reproduce

1. Create secret with terraform in a github repository.
2. Change the actual secret, terraform apply and notice terraform wants to CHANGE the secret.
3. Error occurs and state becomes inconsistent.
4. terraform apply again and notice terraform now wants to ADD the secret (and succeeds).

Additional notes

The secrets are locally "managed" with sops and KMS (also tried with pgp key) but the same problem occurs when using a variable for the secret. A local build is used with the logs (the build only adds a log.Printf for logging the actual updated_at from github.).
I haven't tried it with github_actions_organization_secret but I can imagine it happens there too.

Logs

Terraform shell log: https://gist.github.com/kmeinster/a75e307497e8c1cf311ebde9932aa1d8

[grahame-murray-db]

I'm seeing the same behavior with github_actions_organization_secret

[jvanbrunschot]

We're also running the exact some issue. Using lifecycle policy doesn't help either (to ignore the plaintext & updatedAt values(

[janakerman-form3]

Also running into this issue. After creating a github_actions_organization_secret, the first plan + apply was successful but now all subsequent applies in the workspace are now failing with the same error as above. This is the case even without updating the resource - the plan showed changes even though the secret had not been updated.

[mBlomsterberg]

Running into the same issue. where terraform sees the secret as destroyed after changing the secret values externally. Lifecycle policy set to ignore_changes on plaintext & updated_at.

[jandroav]

Hey! I was wondering if just manually deleting the affected secret and then running the apply will create it from scratch, just to avoid that error. I know the next time it will throw the error again.

[github-actions]

👋 Hey Friends, this issue has been automatically marked as stale because it has no recent activity. It will be closed if no further activity occurs. Please add the Status: Pinned label if you feel that this issue needs to remain open/active. Thank you for your contributions and help in keeping things tidy!

[shinenelson]

Not Stale.

Can someone with access please triage this issue add the Status: Pinned label to this issue please?

[jorgecarleitao]

I can't reproduce this issue on latest:

Given .tf:

provider "github" {}

resource "github_repository" "test" {
    name = "tf-acc-test"
}

variable "value" {
    type = string
}

resource "github_actions_secret" "plaintext_secret" {
    repository       = github_repository.test.name
    secret_name      = "test_plaintext_secret"
    plaintext_value  = var.value
}

resource "github_actions_secret" "encrypted_secret" {
    repository       = github_repository.test.name
    secret_name      = "test_encrypted_secret"
    encrypted_value  = base64encode(var.value)
}

The sequence of commands yields the correct result:

gh auth login
terraform init

terraform apply --var value=a -auto-approve
# Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
terraform apply --var value=b -auto-approve
# Apply complete! Resources: 2 added, 0 changed, 2 destroyed.

Note that what @mBlomsterberg is observing seems a different issue (#1383 and #2288).