drone / charts

Helm charts for the Drone platform on Kubernetes

Drone Helm Charts

This repository hosts official Helm charts for Drone. These charts are used to deploy Drone to Kubernetes.

Install Helm

Read and follow the Helm installation guide.

Note: The charts in this repository require Helm version 3.x or later.

Add the Drone Helm Chart repo

In order to be able to use the charts in this repository, add the name and URL to your Helm client:

helm repo add drone https://charts.drone.io
helm repo update

Install charts

See the the READMEs for the various charts in the charts directory.

• If you have not yet installed Drone server, start with the drone chart.
• After installing drone, install drone-runner-docker to begin executing builds.

Documentation

See Drone or the Drone documentation site for more information.

Kubernetes version support

Due to rapid churn in the Kubernetes ecosystem, charts in this repository assume a version of Kubernetes released in the last 12 months. This typically means one of the last four releases.

Note: While these charts may work with versions of older versions of Kubernetes, only releases made in the last year are eligible for support.

Helm Chart and Drone Support

Visit the support forum for support.

Contributing

For details on how to contribute changes or additions to this repository, see the Contributor's guide.

Please note that the charts within are supplied as a starting point. They are not intended to support every possible Kubernetes configurable. The maintainability of a chart decreases for every additional templated line. We suggest forking the charts if you find yourself needing non-trivial modifications.

License

This repository's contents are licensed under the 2-clause BSD license. See the included LICENSE file for a copy.

charts's Issues

DRONE_GITEA_SERVER is missing in value.yml

Hey,

the DRONE_GITEA_SERVER key is missing in the value.yml of the drone chart. After inserting it I can connect to the Gitea Server normally. It's just a documentation thing.

Thank you.

drone images 2.12.1 build using end of life version of alpine 3.11.13

Drone chart deploys image 2.12.1 and that is build using end of life version of alpine. Please check - https://endoflife.date/alpine

Charts deprecated

I've seen that drone v2.0.0 has been released, but the chart version has since more than a year not been updated. Are the charts deprecated or orphaned?

Maybe an update of the helm charts are required to deploy drone v2.0 in a kubernetes cluster.

drone-runner-kube ingress resource does not correctly configure path and pathType

this commit correctly added support for configuring pathType in ingress resources, but did not update the ingress spec to configure path correctly, and did not update the values.yaml to reflect the correct way to configure ingress.

Without these fixes, it's impossible to apply the drone-runner-kube helm chart version 0.1.9 with ingress.enabled set to true. either the server will reject the ingress resource because it's missing pathType, or the ingress path will be configured with path: map[path:/ pathType:Prefix] which is invalid.

If I attempt to apply the ingress resource with an updated values.yaml (including pathType), the ingress resource attempts to change in the following way:

          paths:
-           - path: /
+           - path: map[path:/ pathType:Prefix]
+             pathType: Prefix

If I attempt to apply the chart with the current values.yaml (with path: ["/"]), the ingress resource validation fails with:

Error: Failed to render chart: exit status 1: Error: template: drone-runner-kube/templates/ingress.yaml:46:23: executing "drone-runner-kube/templates/ingress.yaml" at <.pathType>: can't evaluate field pathType in type interface {}

I use the charts to make up a drone server, but the trigger doesn't work

how to pull image from the private docker-registry

the error log like this:

level=warning msg="registry: plugin: cannot get credentials" error="unexpected end of JSON input"

and I have set the environments like this

DRONE_REGISTRY_SKIP_VERIFY	true
DRONE_REGISTRY_SECRET	admin:$apr1$rH4GFf2e$9wW1bxtvd8GaZCDIfyLPK/
DRONE_REGISTRY_ENDPOINT	https://docker-registry.yizhishang.com

Add helm repo add to individual readme

The Add Helm repository section should be added to individual chart readme, so it's visible on artifacthub.io.

good: https://artifacthub.io/packages/helm/renovate/renovate
bad: https://artifacthub.io/packages/helm/drone/drone

Project settings

how to enable Project settings Trusted

Add support for configuring `nodePort`

Add support for configuring nodePort using helm values

Build fails with spec.containers[2].volumeMounts[0].mountPath: Required value

I have setup a server and runner with the following configs:

drone-values.yml (server)

env:
  DRONE_SERVER_HOST: drone.mydomain.com
  DRONE_SERVER_PROTO: http
  DRONE_RPC_SECRET: mysecret

  DRONE_GITHUB_CLIENT_ID: myid
  DRONE_GITHUB_CLIENT_SECRET: mysecret
  DRONE_USER_CREATE: username:myuser,admin:true

drone-runner-kube-values.yaml (runner)

rbac:
  buildNamespaces:
    - drone

env:
  DRONE_RPC_SECRET: mysecret

  DRONE_NAMESPACE_DEFAULT: drone

when drone gets the webhook call from github for a push, the build fails with:
default: Pod "drone-lcomzc0dunq7m0nr5oea" is invalid: spec.containers[2].volumeMounts[0].mountPath: Required value

I see that I have a persistent volume claim created and connected to the drone/drone image.

Please help me troubleshoot this issue.

Here's my config for the project:

Running the drone-runner as a daemonset

Hello! Drone is great and these helm charts are incredibly useful. This is a question, not an issue.

I changed the drone-runner helm chart from a Deployment to a DaemonSet and I was wondering if there were any downsides of doing this?

Due to the number of resources I need for my pipelines, our cluster autoscaler is busy and nodes are always coming up and going down.

This sticks out in the docs to me

The Kubernetes runner must not be restarted while pipelines are running. If you stop or restart the runner while a pipeline is running, it will be stuck in a running state, and the associated Pod must be manually removed.

I wanted to try a DaemonSet in the hopes that there are always enough runners available and that they wont get rescheduled with all of the autoscaling happening.

So far the only issue I've encountered has been needing to refresh a few times to get the drone-runner UI to load.

Aside from that, are there any gotchas I should be aware of with this approach?

Invalid healthz

Hey, pretty unsure about this but is http://:http/healthz expected at the deployment because my gke health checks are not working (same result local and on gke)

Containers:
   server:
    Image:      drone/drone:2.11.1
    Port:       80/TCP
    Host Port:  0/TCP
    Liveness:   http-get http://:http/healthz delay=0s timeout=1s period=10s #success=1 #failure=3
    Readiness:  http-get http://:http/healthz delay=0s timeout=1s period=10s #success=1 #failure=3

401 Unauthorized when access org secrets

401 Unauthorized when access org secrets. what happend?

clone takes 3 mins

Sometimes the clone plugin takes 3 mins (drone-runner-kube). Is there anything i can debug?

stuck in state `default: Pending` on gcloud k8s cluster

I tried to follow the steps mentioned here https://github.com/drone/charts.

I created a k8s cluster on gcloud and performed in sequence below steps:

1. k8s in google cloud I can access from my machine.

2. I added chart in helm

helm repo add drone https://charts.drone.io
helm repo update

3. I created drone-values.yaml

service:
  type: LoadBalancer
env:
  DRONE_SERVER_HOST: drone.example.com
  DRONE_SERVER_PROTO: http
  DRONE_RPC_SECRET: secret
  DRONE_GITHUB_CLIENT_ID: xxxxxxxxxxxxxxxxxxxxxxx
  DRONE_GITHUB_CLIENT_SECRET: yyyyyyyyyyyyyyyyyyyyy
  DRONE_USER_CREATE: username:kushwahashiv,admin:true

4. installed drone

kubectl create ns drone
helm install --namespace drone drone drone/drone -f drone-values.yaml

All the pods were created and running

5. I created a file rone-runner-kube-values.yaml with below content

rbac:
  buildNamespaces:
    - drone

env:
  DRONE_RPC_SECRET: secret
  DRONE_NAMESPACE_DEFAULT: drone

6. Installed runner

helm install --namespace drone drone-runner-kube drone/drone-runner-kube -f drone-runner-kube-values.yaml

All the pods running successfully.

7. When I sync repos and try to change the repo it triggers a build

Above build is now stuck for forever in a default: Pending state

I'm not sure which step I'm missing to setup the drone on google cloud.

Breaking environment

Upgrading to 0.5.0 (commit f058f76) is breaking our whole system with drone chart 0.4.0 and droner-runner-kube chart 0.1.9

the drone-runner-kube can't ping the remote server anymore

securityContext example misleading / port 80 hardcoded

the securityContext section in the default values.yaml implies that dropping all capabilities and running as non-root is possible; however this quickly fails because the chart seemingly is hardcoded to have drone listen on port 80.

Add support for gateway API

The Gateway API has reached v1 and implemenatation are starting to arrive. Please add Gateway API templates to the helm chart that can be selected in lieu of Ingress templates. Thank you!

Can't deploy drone helm chart on EKS

I've configured drone helm chart and when deploy it, right away fails

No clear error output, why it's failing.
Error logs:

{"level":"fatal","msg":"main: source code management system not configured","time":"2024-02-21T19:53:09Z"}

What am I missing any suggestions?

Missing provider specific configuration

Currently, server chart is too generic and does not support provider specific configurations. Things like DRONE_STASH_PRIVATE_KEY have to be created beforehand and mounted separately.

Perhaps such values could be supplied during installation step. Prior to submitting PR would love to know what are your suggestions regarding chart structure.

Unable to start a new build: json: cannot unmarshal number into Go value of type gogs.commitDetail

error happens where new build after install by charts.

Unable to start a new build: json: cannot unmarshal number into Go value of type gogs.commitDetail

here is the .drone.yml file

---
kind: pipeline
type: kubernetes
name: default

steps:
- name: greeting
  image: alpine
  commands:
  - echo world
trigger:
  event:
  - push

dron runner SA lacks required credentials

after installing drone runners by

helm upgrade drone-runner drone/drone-runner-kube --install --create-namespace --namespace drone --values runner.yaml

with values:

replicaCount: 2
env:
  DRONE_RPC_SECRET: aaaa
  DRONE_NAMESPACE_DEFAULT: drone

I'm getting

default: secrets is forbidden: User "system:serviceaccount:drone:drone-runner-drone-runner-kube" cannot create resource "secrets" in API group "" in the namespace "drone"

when running a pipeline

Chart for vault-secrets

First of all thank you for providing your own helm-chart repository. Recently we've migrated to this one from "stable".

Are there any plans to add a chart for vault-secrets?

artifacthub.io metadata

Move the chart repo on artifact.io to drone org.

I've invited @gtaylor to the newly created org. He can remove me after accepting.

After this some repo metadata should be added. see https://artifacthub.io/docs/topics/repositories/#helm-charts-repositories

I'm happy to send a pr.

• https://artifacthub.io/packages/helm/drone/drone
• https://artifacthub.io/docs/topics/repositories/#ownership-claim
• https://artifacthub.io/docs/topics/repositories/#official-status

Update image tags in default values.yaml

I'm not sure if the chart needs other changes, but both the server and the kube runner are pointing to old versions by default (1.6.5 vs 1.7.0 and beta.1 vs beta.3).

Helm charts hard-coded to use HTTP

USE CASE

My use case is to setup a CICD solution in my homelab for a private repository hosted on Github. When activating a repository, a Github Webhook is created that attempts to preforms an HTTP post operation against my hostname against the /hook path.

PROBLEM

The charts are hard-coded to use the HTTP port instead of HTTPS which is explicitly discouraged by Github for webhooks. Examples of this can be found in the deployment, service, and ingress templates:

charts/charts/drone/templates/deployment.yaml

Lines 38 to 41 in cfb5b85

	ports:
	- name: http
	containerPort: 80
	protocol: TCP

charts/charts/drone/templates/service.yaml

Lines 10 to 13 in cfb5b85

	- port: {{ .Values.service.port }}
	targetPort: http
	protocol: TCP
	name: http

charts/charts/drone/templates/ingress.yaml

Lines 31 to 39 in cfb5b85

	- host: {{ .host | quote }}
	http:
	paths:
	{{- range .paths }}
	- path: {{ . }}
	backend:
	serviceName: {{ $fullName }}
	servicePort: {{ $svcPort }}
	{{- end }}

Because the chart is hard coded for HTTP, it prevents from using other features like DRONE_TLS_AUTOCERT or manually providing TLS certificates to align with Github best practices.

Wrong image urls

It seems the https://drone.io/apple-touch-icon.png image no longer exists.

error getting logo image https://drone.io/apple-touch-icon.png: unexpected status code received: 404 (package: drone version: 0.2.5)
error getting logo image https://drone.io/apple-touch-icon.png: unexpected status code received: 404 (package: drone-kubernetes-secrets version: 0.1.2)
error getting logo image https://drone.io/apple-touch-icon.png: unexpected status code received: 404 (package: drone-runner-docker version: 0.1.0-rc.3)
error getting logo image https://drone.io/apple-touch-icon.png: unexpected status code received: 404 (package: drone-runner-kube version: 0.1.8)

https://artifacthub.io/control-panel/repositories?modal=tracking&user-alias=&org-name=drone&repo-name=drone

Chart stores secrets in ConfigMap rather than Secret

Values such as DRONE_DATABASE_SECRET, DRONE_RPC_SECRET, DRONE_GITEA_CLIENT_SECRET (and similar such secrets from other providers) are stored in a ConfigMap rather than a K8s Secret.

I understand I can use extraSecretNamesForEnvFrom and pass my own pre-created secret, but of course the value proposition of the Helm chart is that it creates K8s resources for me. I use the Helm Secrets plugin that allows security passing secret values into Helm charts, and I'd prefer to use this mechanism for Drone secrets as well, rather than manually create a secret outside the chart.

Perhaps a separate envSecrets in the Helm chart, to facilitate this? Something like:

env:
  DRONE_SERVER_HOST: drone.example.com
  DRONE_SERVER_PROTO: https
  DRONE_GITEA_SERVER: https://git.examle.com
  DRONE_GITEA_CLIENT_ID: 9e145da5-692b-42a1-999b-3f09b103906c

envSecrets:
  DRONE_DATABASE_SECRET: d6a7835fd429a27e3f96fc64962f7b0c
  DRONE_RPC_SECRET: c9da1cd55e4f57c6026a0cf47d94f5b7
  DRONE_GITEA_CLIENT_SECRET: +1dV0BB024M/qkIrwPqO5J27tG7WhOCX3d3tXmqPMes=

Or, maybe the chart could be clever enough to automagically place everything matching *_SECRET into a k8s secret.

Happy to submit a PR if you'd accept it.

How to run drone/drone-admit-members with Helm?

It would be good to have either this component optionally included in the main drone chart or have it as a separate chart. I can make a PR? Which would you prefer?

Issue with deploying Drone Runner on GKE Autopilot - Connection and Permission Errors

Description:
I deployed Drone Runner on GKE Autopilot following the official documentation, and my parameter settings are as follows:

env:
  DRONE_RPC_SECRET: test
  DRONE_SECRET_PLUGIN_ENDPOINT: http://drone-kubernetes-secrets:3000
  DRONE_SECRET_PLUGIN_TOKEN: test
  DRONE_RUNNER_NETWORK_OPTS: "com.docker.network.driver.mtu:12345"
dind: 
  commandArgs:
    - "--host"
    - "tcp://localhost:2375"
    - "--mtu=12345"
  securityContext:
    privileged: false

podSecurityContext:
  fsGroup: 2000
securityContext:
  capabilities:
    drop:
    - ALL
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  runAsUser: 1000

However, when I check the logs of the Runner pod, I encountered the following errors:

grpc: addrConn.createTransport failed to connect to {unix:///var/run/docker/containerd/containerd.sock <nil> 0 <nil>}. Err :connection error: desc = \"transport: Error while dialing dial unix:///var/run/docker/containerd/containerd.sock: timeout\". Reconnecting..." module=grpc
failed to start daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables -t nat -N DOCKER: iptables v1.8.9 (legacy): can't initialize iptables table `nat': Permission denied (you must be root)

I'm seeking assistance on how to resolve and adjust the configuration for the mentioned issues.

Thank you.

Can't attach extra volumes to docker-runner

Why is there no ability to define and attach extra volumes to the docker-runner deployment?

I want to use the DOCKER_RUNNER_ENV_FILE environment variable to inject environment variables into the pipelines.

I'd like to define things like a Docker registry mirror, custom DNS servers, etc.

I see there are appropriate fields in the values schema, but they're not used in the docker-runner deployment.

Edit: I want to use a file, rather than the available DOCKER_RUNNER_ENV environment variable, because in fields like the Docker registry mirror URL there are colons, which are not parsed correctly when provided through this variable.

Improve Documentation

Improve Documentation to add details on how to configure the secrets that is used in the helm values.

Is this project active?

I see that the app version used by this chart is lagging behind the releases of harness/drone by a year. Should this chart be considered deprecated/archived?

If so, please clarify that in the README and perhaps mark the repo as archived in GitHub.

If not, please update the chart. 😄

I was going to ask on Slack, but that's apparently locked down to Harness employees only.

Master chart 1.1.5 while published chart is 1.1.3

First off, loving Drone and I like that you've taken ownership of maintaining a repo to properly deploy Drone to Kubernetes, with all the bells and whistles.

I found an issue trying to migrate from community charts to this one. When I went to deploy it to a sandbox to test out values, helm was unable to find the version of the chart pointed to by the master branch, 1.1.5. When reading the published chart repo index, I see the only chart version published for the drone server chart is 1.1.3.

Has the CI publish job not run?

kube runner: unable to run (gke autopilot)

Helm charts requires DRONE_RPC_SECRET when it may already be provided by extraSecretNamesForEnvFrom secret

PROBLEM
When providing secrets using the extraSecretNamesForEnvFrom method, helm3 still raises an error that the DRONE_RPC_SECRET environment variable is missing.

STEPS

1. Create a Kubernetes environment, setup Helm 3, add the drone repo, and update. (I used microk8s for this)
2. Create a drone namespace.
3. Create a drone-secret Kubernetes secret in the drone namespace similar to the following...

apiVersion: v1
kind: Secret
metadata:
  name: drone-secret
  namespace: drone
data:
  DRONE_RPC_SECRET: ***
  DRONE_GITHUB_CLIENT_ID: ***
  DRONE_GITHUB_CLIENT_SECRET: ***

4. Create a values file that makes reference to the secret that looks similar to the following...

service:
  type: LoadBalancer
 
extraSecretNamesForEnvFrom:
  - drone-secret

env:
  DRONE_SERVER_HOST: drone.domain.local
  DRONE_SERVER_PROTO: https

5. Attempt to install drone using the helm chart using a command similar to the following:
6. Observe.

OBSERVED
The command returns the following error:

Error: values don't meet the specifications of the schema(s) in the following chart(s):
drone:
- env: DRONE_RPC_SECRET is required

EXPECTED
The DRONE_RPC_SECRET would be pulled from the Kubernetes Secret, so it should not be prompting the user as if it was not already provided.

WORKAROUND
Add a bogus value for the DRONE_RPC_SECRET environment variable in the values.yaml file.

SOLUTION
Remove references to DRONE_RPC_SECRET from the required properties in the values.schema.json file.
This can be done in the following places:

charts/charts/drone/values.schema.json

Line 153 in dd2668e

"DRONE_RPC_SECRET"

charts/charts/drone-runner-kube/values.schema.json

Line 168 in dd2668e

"DRONE_RPC_SECRET"