👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labeled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

I've updated the implementation to not require a recreate now that the diff is being handled correctly. I've also updated the pattern to correctly handle repo identity and support repo renames.

There is an open PR for adding import of resourceGithubActionsEnvironmentSecret
https://github.com/integrations/terraform-provider-github/pull/2462/changes#diff-bd7e54bc1e5ce2c06ae7d38565efee3c760620c960497f9c1d6db2f230415cbc

should that be taken into account or closed?

Further prior art on this topic: #2499

This might resolve #2047

Tested this in a project and confirmed it's working as intended - updating selected_repositories now results in updating existing org secrets rather then replacing them. Eagerly awaiting the release of v6.11.0.

Scratch that - secrets showed that they would be updated in place, but the actual secret value was cleared (edit: unsure if it was cleared or set to something else, but it was definitely changed).

Example output from the apply of a secret whose value was wiped:

22:07:24.464 STDOUT terraform:   # github_actions_organization_secret.this["VERCEL_TOKEN"] will be updated in-place
22:07:24.464 STDOUT terraform:   ~ resource "github_actions_organization_secret" "this" {
22:07:24.464 STDOUT terraform:         id                      = "VERCEL_TOKEN"
22:07:24.464 STDOUT terraform:       ~ selected_repository_ids = [
22:07:24.464 STDOUT terraform:           + 1148597881,
22:07:24.464 STDOUT terraform:             # (1 unchanged element hidden)
22:07:24.464 STDOUT terraform:         ]
22:07:24.464 STDOUT terraform:         # (8 unchanged attributes hidden)
22:07:24.464 STDOUT terraform:     }

@Piccirello the secret will always be set to the value that you provide in the config unless you've used a lifecycle ignore changes? But even if you're using ignore changes, changing the selected repos will update the secret to the value in config. How come you're not using the specific resources for managing selected repos outside of the actual secret?

The secret is defined with ignore_changes = [plaintext_value, encrypted_value, destroy_on_drift].

How come you're not using the specific resources for managing selected repos outside of the actual secret?

We're using the selected_repository_ids field of the github_actions_organization_secret resource. Should we be using github_actions_organization_secret_repositories? Our current goal is to create the secrets and manage their selected repositories via TF, but otherwise set the raw value via github.com.

@Piccirello your current pattern won't work as changing the selected repos will cause the secret value to be updated even if it's in lifecycle ignore changes. You should be using github_actions_organization_secret_repositories, but as far as I can tell this is currently causing drift to github_actions_organization_secret in both the released code and main. I've just opened #3155 to fix this, so it should be in the next release alongside these changes.

qq - what's the platform-side impact of applying the changes to destroy_on_drift when going from v5 to v6 now?

https://registry.terraform.io/providers/integrations/github/latest/docs/resources/actions_organization_secret#destroy_on_drift-1

Applying the below causes the secret to be updated in some way on the GH side, trying to understand what, or if it's just a one-time push of the same secret values?

  # github_actions_organization_secret.EVAN_TEST will be updated in-place
  ~ resource "github_actions_organization_secret" "EVAN_TEST" {
      - destroy_on_drift  = true -> null
        id                = "EVAN_TEST"
        # (7 unchanged attributes hidden)
    }

@evanrappe it's a no-op as destroy_on_drift no longer serves any purpose. It should clean itself up?

@stevehipwell yeah its a clean apply the second time, but I'm just curious what it's actually doing on the GH api when you apply the above one-time drift, as it updates the "last updated" time for the secret on the page that lists the secrets.

@evanrappe for clarity it's not a no-op, as it is putting the same secret back (it doesn't know what the secret it), but it should have no effect on your configuration. I removed the default value for destroy_on_drift so it gets cleaned up. If you want an actual no-op you could chose to set destroy_on_drift, but then you'd need to remove it before the next major version release, or add a lifecycle ignore for it.