Add Gitea API token for toolshed's webhook management
This commit is contained in:
@@ -0,0 +1,38 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user