argocd_repository_credentials: ID is set to URL instead of ID

[jervi]

When creating an argocd_repository_credentials resource, there's no way to give it a proper name, which means Argo will create a secret called something like creds-012345678. Furthermore, the argocd_repository_credentials doesn't expose this generated name anywhere. The actual id field is set to URL instead.
This makes it hard to use the credentials with for instance the pull_request generator in an ApplicationSet, because it requires the actual name of the secret.

This can probably be solved in one of two ways:

• Let the user provide a well defined name for the argocd_repository_credentials resource; or
• Return the generated id/name instead of the URL.

Terraform Version, ArgoCD Provider Version and ArgoCD Version

Terraform version: 1.11.3
ArgoCD provider version: 7.12.5
ArgoCD version: 3.3.0

Affected Resource(s)

• argocd_repository_credentials

Terraform Configuration Files

resource "argocd_repository_credentials" "gh-creds-platform-engineering" {
  url                           = "https://acme.ghe.com/platform-engineering/"
  githubapp_id                  = "1234"
  githubapp_installation_id     = "5678"
  githubapp_enterprise_base_url = "https://acme.ghe.com/api/v3"
  githubapp_private_key         = jsondecode(data.aws_secretsmanager_secret_version.argocd_repo_creds.secret_string)["githubAppPrivateKey"]
}

# Inside argocd_application_set:
generator {
  pull_request {
    requeue_after_seconds = 120
    github {
      api             = "https://api.acme.ghe.com"
      owner           = "platform-engineering"
      repo            = "backstage"
      app_secret_name = "creds-152247523" # Need to hardcode secret reference here, because there's no way to get the correct ID (`argocd_repository_credentials.gh-creds-platform-engineering.id` returns `https://acme.ghe.com/platform-engineering/`)
    }
  }
}

Steps to Reproduce

1. Create an argocd_repository_credentials like above
2. Try to get the id from the resource, like argocd_repository_credentials.my_repo_creds.id

Expected Behavior

The id/name of the resource should be returned, e.g. creds-152247523.

Actual Behavior

The URL is returned instead, e.g. https://acme.ghe.com/platform-engineering/.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[the-technat]

I'd be in favor of adding a new computed field secret_name to the schema to get this value back into the Terraform state for backwards compatibility and not having to do state migrations. In Argo CD a repository credential is uniquely identified by it's URL and all of the Argo CD API uses the URL as identifier, not the name of the k8s secret it's stored in.

[the-technat]

Rereading the Argo CD API docs I see that the name of the k8s secret is never returned, even more so the AppSet PR Generator's tokenRef doesn't refer to a git repository but a secret storing the token for accessing the respective SCM. Could it be that you mixed something up there?

[jervi]

In Argo CD a repository credential is uniquely identified by it's URL and all of the Argo CD API uses the URL as identifier, not the name of the k8s secret it's stored in.

That is true in most places, but not for the GitHub pull request generator. This needs an app secret name or a token (which makes sense, as this generator talks to the GitHub API and is not a regular git provider). However, if you configured your git credentials using a GitHub app, you can use the same credentials for both regular git access and GitHub API access. All you’re missing is the name of the k8s secret.

Rereading the Argo CD API docs I see that the name of the k8s secret is never returned, even more so the AppSet PR Generator's tokenRef doesn't refer to a git repository but a secret storing the token for accessing the respective SCM. Could it be that you mixed something up there?

As I wrote above, if you use a GitHub app for authentication, then you can use the same credentials for both. And note that I’m not using tokenRef, but appSecretName. But it is entirely possible that the real issue here is that the ArgoCD API doesn’t return this value, not much to do in this provider then 😕

[the-technat]

🙈 should have better read the issue description. Now that you mention it, that's surely a valid use case to reuse the same credential for both.

But as mentioned, it's gonna be hard to find out the exact secret name if Argo CD's API doesn't return that value. We could hyper-theoretically query the secrets in the namespace and find the appropriate one, but that only works if the provider has valid creds for the kubeapi, which it only has if used with port-forwarding, and even then the user that's allowed to port-forward to the argocd server should probably not be able to read all secrets in the Argo CD namespace...

To verify this is the case you might wanna try creating a repo cred using curl or similar and see what the response looks like, but as far as I understand the Swagger API docs it's not part of the response.

You might want to open an issue upstream though. If the API provides this value it's straightforward to feed that back into a computed field on the resource.

[jervi]

Yeah, I'll investigate a bit and open an upstream issue. We can put this issue on hold (or close it) and continue if/when it's fixed upstream 👍 Thanks a lot for looking into it, @the-technat!

[jervi]

There's already an open ticket for this issue: argoproj/argo-cd#23233