
Interestingly, the existence of this chart somewhat contradicts the [docs](https://docs.drone.io/runner/extensions/kube/), which suggest you should "_\[d\]eploy the secret extension in the same Pod as your Kubernetes runner_". Though the interaction appears to be via an HTTP call, so that doesn't seem like would be an issue.
TODO:
- Create the following in an initContainer if they don't exist:
- The Gitea OAuth application at startup
- The Prometheus user (https://cogarius.medium.com/3-3-complete-guide-to-ci-cd-pipelines-with-drone-io-on-kubernetes-drone-metrics-with-prometheus-c2668e42b03f) - probably by mounting the volume, using sqlite3 to parse out admin password, then using that to make API call
- Create
gitea_password
Organization Secret at init.
Ensure that Vault has a secret at shared-secrets/gitea/oauth-creds
with keys DRONE_GITEA_CLIENT_ID
and DRONE_GITEA_CLIENT_SECRET
(see the application definition in app-of-apps/drone.jsonnet
to see how the secret is injected from Vault into k8s). Remember also to create an Organization Secret named gitea_password
for pulling.
For MTU problem diagnosis:
https://github.com/gliderlabs/docker-alpine/issues/307#issuecomment-634852419
https://liejuntao001.medium.com/fix-docker-in-docker-network-issue-in-kubernetes-cc18c229d9e5