Add option to create SSH keys using `CreatePublicKey` instead of `AdminCreateUserPublicKey`

[stephen-bracken]

The forgejo_ssh_key resource uses the AdminCreateUserPublicKey method from the forgejo client to create a public key for a given user:

terraform-provider-forgejo/internal/provider/ssh_key_resource.go

Line 208 in d3b15f4

key, res, err := r.client.AdminCreateUserPublicKey(

This requires an admin account to be provided in the provider credentials. Instead it should be possible to create ssh keys for the provider user as non-admin using the CreatePublicKey method:
https://codeberg.org/mvdkleijn/forgejo-sdk/src/commit/75e5a725cf15e0025bf635fd6f0efa9b24e15b1f/forgejo/user_key.go#L73

This would allow the terraform to be used with pre-existing non-admin users e.g.

locals {
    username    = "my_svc"
    password    = "my_svc_password"
    forgejo_url = "https://forgejo.example.com"
}

provider "tls" {}

provider "forgejo" {
  alias    = "my_svc"
  host     = local.forgejo_url
  username = local.username
  password = local.password
}

resource "tls_private_key" "ssh_key" {
  algorithm = "ED25519"
}

data "forgejo_user" "user" {
  provider = forgejo.my_svc

  login    = local.username
}

resource "forgejo_ssh_key" "ssh_key" {
  provider        = forgejo.my_svc

  user            = data.forgejo_user.user.login
  key             = trimspace(tls_private_key.ssh_key.public_key_openssh)
  title           = "terraform"
  create_as_admin = false  # Add this option to disable the admin client
}

This allows a terraform module that has access to existing user credentials to create SSH keys for those users without needing to provide admin credentials for forgejo:

provider "forgejo" {
  alias    = "my_svc"
  host     = local.forgejo_url
  username = "my_svc"
  password = "my_svc_password"
}

module "forgejo_ssh_my_svc" {

  providers = {
    forgejo = forgejo.my_svc
  }

    ...
}

[kad-hollac1]

I would say that specifying the user triggers the admin-route whilst omitting the user uses the user-route. (Cf. also the GPG key resource, https://registry.terraform.io/providers/svalabs/forgejo/latest/docs/resources/gpg_key, which omits the user altogether.)

[stephen-bracken]

I would say that specifying the user triggers the admin-route whilst omitting the user uses the user-route. (Cf. also the GPG key resource, https://registry.terraform.io/providers/svalabs/forgejo/latest/docs/resources/gpg_key, which omits the user altogether.)

This could work, but I would prefer to have it explicit whether to use the admin route.
The GPG key resource is used with the gpg_key_pair resource to associate the key with a user. I agree that the non-admin route would look similar, where the foregejo_gpg_key resource uses the client.CreateGPGKey() method to create the key:

terraform-provider-forgejo/internal/provider/gpg_key_resource.go

Line 336 in 2418bb8

key, res, err := r.client.CreateGPGKey(opts)

[acch]

I agree with @kad-hollac1 in that I would favor similar, consistent resource semantics across forgejo_repository (already implemented), forgejo_ssh_key, and forgejo_gpg_key (if possible):

• If practitioners do not specify a owner attribute, this means that the resource is created for the authenticated user, which does not require admin privileges (non-admin route):

  # personal repo
  resource "forgejo_repository" "example" {
    name        = "new_personal_repo"
    description = "Purely for testing..."
  }

• If practitioners do specify a owner attribute, this means that the resource is created for the given user, which requires admin privileges (admin route):

  # user repo
  resource "forgejo_repository" "example" {
    owner       = forgejo_user.owner.login
    name        = "new_user_repo"
    description = "Purely for testing..."
  }

• The rules are explicit, and can be unambiguously documented like so:

  **Note**: Managing user repositories requires administrative privileges!
  

• I think I prefer the term owner over user, as it describes the relationship the repo / key has with the specified user - but I'm open to suggestions!

@stephen-bracken Does this make sense to you?

[stephen-bracken]

@acch I don't have a strong preference here, your proposal works for my use case.