[BUG]: github_actions_organization_secret - Provider produced inconsistent result after apply

[dion-gionet]

Expected Behavior

No errors when updating github_actions_organization_secret selected_repository_ids

Actual Behavior

Applying this change

# github_actions_organization_secret.secret["foo"] will be updated in-place
 ~ resource "github_actions_organization_secret" "secret" {
       id                      = "foo"
     ~ selected_repository_ids = [
         + 1,
         + 2,
           # (250 unchanged elements hidden)
       ]
       # (5 unchanged attributes hidden)
   }

Results in

│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to github_actions_organization_secret.secret["foo"], provider "provider[\"registry.terraform.io/integrations/github\"]" produced an unexpected new
│ value: Root resource was present, but now absent.
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

The same bug is also present with github_dependabot_organization_secret using the same config.
After the apply, the next plan wants to create the resource.

  # github_actions_organization_secret.secret["foo"] will be created
  + resource "github_actions_organization_secret" "secret" {
      + created_at              = (known after apply)
      + id                      = (known after apply)
      + plaintext_value         = (sensitive value)
      + secret_name             = "foo"
      + selected_repository_ids = [
          + 1,
          + 2,
        ]
      + updated_at              = (known after apply)
      + visibility              = "selected"
    }

Terraform Version

Terraform v1.5.4
on darwin_amd64

• provider registry.terraform.io/devolutions/azurerm v1.0.2
• provider registry.terraform.io/integrations/github v5.38.0

Affected Resource(s)

• github_actions_organization_secret
• github_dependabot_organization_secret

Terraform Configuration Files

resource "github_actions_organization_secret" "secret" {
  for_each                = local.secrets
  secret_name             = each.key
  visibility              = each.value["visibility"]
  plaintext_value         = data.azurerm_key_vault_secret.secret[each.key].value
  selected_repository_ids = each.value["visibility"] == "selected" ? local.selected_repo_ids : []
}

Steps to Reproduce

Update the list of selected_repository_ids then apply

Debug Output

No response

Panic Output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[laughedelic]

I've got the same error:

github_actions_organization_secret.secret_name: Modifying... [id=SECRET_NAME]

Error: Provider produced inconsistent result after apply

When applying changes to
github_actions_organization_secret.secret_name, provider
"provider[\"registry.terraform.io/integrations/github\"]" produced an
unexpected new value: Root object was present, but now absent.

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

This secret was initially imported and worked fine. After this failed apply (changing selected_repository_ids) I can't apply without "creating" it again. But the secret is in the state:

►  terraform state show github_actions_organization_secret.secret_name
# github_actions_organization_secret.secret_name:
resource "github_actions_organization_secret" "secret_name" {
    created_at              = "2024-03-08 14:24:27 +0000 UTC"
    id                      = "SECRET_NAME"
    secret_name             = "SECRET_NAME"
    selected_repository_ids = [
      ...
    ]
    updated_at              = "2024-03-08 14:24:27 +0000 UTC"
    visibility              = "selected"
}

if I run plan it says

# github_actions_organization_secret.secret_name will be created

so I'm not sure if this will destroy the existing secret, replace it, or have no effect.

Same thing happens with a github_dependabot_organization_secret resource.

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

[dion-gionet]

This still happens

[jorgecarleitao]

minimal reproducible example:

provider "github" {}

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

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

variable use_both_repos {
  type = bool
}

resource "github_actions_organization_secret" "main" {
  secret_name = "BLAAA"
  plaintext_value = "aaa"
  visibility = "selected"
  selected_repository_ids = var.use_both_repos ? [
    github_repository.test_repo_1.repo_id,
    github_repository.test_repo_2.repo_id
  ] : [github_repository.test_repo_1.repo_id]
}

and run

gh auth login
gh auth refresh --scopes admin:org

export GITHUB_OWNER=test-org-for-tf-1
terraform apply -var use_both_repos=true -auto-approve
terraform apply -var use_both_repos=false -auto-approve

[jorgecarleitao]

The underlying issue is that changing selected_repository_ids on github results in a change of update_at.

This in turn results in us identifying that the secret's value change, which results in the creation of a new secret (which #2499 converts to an update, separate issue #1383).

AFAIK this is not possible to mitigate - we have no mechanism to distinguish whether update_at changed due a change of selected_repository_ids or due to a change of plaintext_secret - both result in a new update_at.

IMO we need to escalate to GitHub's API team - imo they need to provide a value_update_at that allow us to verify whether the secret changed. This need is not limited to our use-case - from an security/audit perspective, knowing when the secret value last changed is important when we cannot read said value.