# Gitea API token for toolshed's builder, used to configure repository push
# webhooks so nobody has to add one by hand.
#
# builder holds this alongside its Jenkins credentials — it is the worker that
# talks to external systems. api deliberately holds neither: it is the most
# exposed service in the deployment, and keeping it unable to reach anything
# but its own database is the point of the split.
#
# Create the token in Gitea under Settings -> Applications -> Generate Token.
# Gitea 1.20 and later can scope tokens; write:repository is enough, and is
# considerably less than a full-access token. The account needs write access
# to the repositories toolshed will manage hooks on, so for repositories owned
# by one person their own token is the smallest thing that works.
#
#   kubectl -n vault exec -i vault-0 -- sh -lc '
#     vault login <root-token> >/dev/null &&
#     vault kv put secret/toolshed/gitea token=<api token>'
#
# Optional. Without it builder logs that webhooks must be added by hand and
# the dashboard says the same, rather than failing anything.
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: toolshed-gitea
  namespace: toolshed
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: toolshed-gitea
    creationPolicy: Owner
  data:
    - secretKey: token
      remoteRef:
        key: toolshed/gitea
        property: token