When github_actions_secret is changes via gui, it will be re-created

[ArneRiemann4711]

Terraform Version

1.0.7

Affected Resource(s)

Please list the resources as a list, for example:

• github_actions_secret

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

resource "github_actions_secret" "workflow_pat" {

  count = var.create_default_secrets ? 1 : 0

  repository      = github_repository.this.name
  secret_name     = "WORKFLOW_PAT"
  plaintext_value = "CHANGE_ME"

  lifecycle {
    ignore_changes = [plaintext_value]
  }
}

Expected Behavior

Changes to Secrets made from GitHub Gui should be ignored

Actual Behavior

Secret will be re-created

Steps to Reproduce

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

1. terraform apply

Repo is created from a template. Could this be the reason?

[thekbb]

This is expected, terraform is fixing config drift. Changes to a terraform managed resource made outside of terraform will be put back when terraform applies.

Things should either be managed through terraform or not... there is no middle path.

[gfoligna-nyshex]

I think the ignore_changes lifecycle argument is there on purpose.

I'm having the same issue. I get a total new creation of the github_actions_secret every time I plan and apply. None of the arguments from ignore_changes works for me.

TF ver 0.13.5 GitHub provider ver 4.7.0 (latest as of today)

This is expected, terraform is fixing config drift. Changes to a terraform managed resource made outside of terraform will be put back when terraform applies.

Things should either be managed through terraform or not... there is no middle path.

[gfoligna-nyshex]

Also this relates to #749

[gfoligna-nyshex]

One more thing: v0.14.1 claims to have this error fixed. Tested and it is still not working (actually just worked once).

[atanaspam]

We are also running into this issue.

Seems to be related to this piece of code that does not respect the ignore_changes lifecycle argument.

[yordis]

Following this,

Our intention at the moment is to provision the secrets without the values (just as a templating) to then manually update the secret values, but every time we do it the resource gets destroyed and recreated again.

[github-actions[bot]]

👋 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!

[yordis]

keep

[github-actions[bot]]

👋 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!

[yordis]

Could somebody try to directly help at #1351

[mrsaiz]

We are also facing this issue. In AWS terraform provider, the way it is manage is using two different resources, secret and secret_version.

resource "aws_secretsmanager_secret" "example" {
  name = "example"
}

resource "aws_secretsmanager_secret_version" "example" {
  secret_id     = aws_secretsmanager_secret.example.id
  secret_string = "example-string-to-protect"
}

I can create an "empty" secret with terraform, then manage the secret_version out of terraform state.

It would be nice to manage github secrets in a similar way. The day 1, I want to create the secret with terraform but, day 2, manage the rotation with a separated tool.

[nickfloyd]

This feels like another destroy_on_drift scenario much like this recent changeset. My guess from the discussion is that we need to add the property to resourceGithubActionsSecret for those who want to override the default behavior. I can work up a PR but I'd like another confirmation as a gut check to ensure I'd be addressing the actual need here.

I'll work something up with schema migrations as well to help to close this out.