How can I specify build step resource requirements (cpu/memory) for the build step when running on Kubernetes?
How can the state on disk be shared between steps?
I’m looking to the functionality that will resemble “volumes” in google cloud build https://cloud.google.com/cloud-build/docs/build-config#volumes
How can I specify build step resource requirements (cpu/memory) for the build step when running on Kubernetes?
You can set resource requirements for each pipeline step in the yaml:
https://docs.drone.io/pipeline/kubernetes/syntax/steps/#resources
How can the state on disk be shared between steps?
I’m looking to the functionality that will resemble “volumes” in google cloud build
See Volumes | Drone and
Workspace | Drone
Thank you for your help
For some reason I do not understand my pipelines are always executed as docker, even if I specify them as
kind: pipeline
name: build-deploy
type: kubernetes
Please provide more details such as your Drone version, your server and runner configuration, and steps that can be used to reproduce. There are three ways that a Kubernetes pipeline can execute as a Docker pipeline:
drone exec which does not integrate with KubernetesWe are using drone 1.6.5
The pipeline is configured like that (some stuff is omitted)
kind: pipeline
name: build-deploy
type: kubernetes
steps:
- name: build
image: xyz
detach: false
entrypoint: [bash]
volumes:
- name: cache
path: /root/.m2
commands:
- lein do junit install
when:
event:
- push
- name: deploy
image: yyy
detach: false
entrypoint: [bash]
commands:
- lein do deploy
when:
branch:
- master
event:
- push
- name: slack
image: plugins/slack
detach: false
settings:
webhook:
from_secret: drone-webhook
channel: drone-io
when:
status: [ success, failure ]Can you please provide both you server and runner configuration details? I think we are missing some context around your installation.
This is the statefulset.yaml (some stuff removed)
apiVersion: v1
kind: Service
metadata:
name: drone
labels:
app: drone
spec:
ports:
- port: 80
targetPort: http
protocol: TCP
name: http
- port: 443
targetPort: https
protocol: TCP
name: https
type: NodePort
selector:
app: drone
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: drone
spec:
selector:
matchLabels:
app: drone
serviceName: drone
replicas: 1
template:
metadata:
labels:
app: drone
spec:
terminationGracePeriodSeconds: 10
containers:
- name: drone
image: drone/drone:1.6.5
imagePullPolicy: Always
env:
- name: DRONE_LICENSE
value: /license/drone.key
- name: DRONE_KUBERNETES_ENABLED
value: "true"
- name: DRONE_KUBERNETES_NAMESPACE
value: drone
- name: DRONE_GITHUB_SERVER
value: https://github.com
- name: DRONE_GITHUB_CLIENT_ID
valueFrom:
secretKeyRef:
name: drone
key: github-client-id
- name: DRONE_GITHUB_CLIENT_SECRET
valueFrom:
secretKeyRef:
name: drone
key: github-client-secret
- name: DRONE_RPC_SECRET
valueFrom:
secretKeyRef:
name: drone
key: rpc-secret
- name: DRONE_SECRET_SECRET
valueFrom:
secretKeyRef:
name: vault-plugin-secret
key: secret
- name: DRONE_SECRET_ENDPOINT
value: http://kubernetes-secrets:3000
- name: DRONE_SERVER_HOST
value: xxxx
- name: DRONE_SERVER_PROTO
value: https
- name: DRONE_GIT_ALWAYS_AUTH
value: "true"
- name: DRONE_USER_FILTER
value: yyyyy
- name: DRONE_REPOSITORY_FILTER
value: xxx
- name: DRONE_LOGS_DEBUG
value: "true"
ports:
- containerPort: 443
name: https
- containerPort: 80
name: http
readinessProbe:
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 15
periodSeconds: 15
livenessProbe:
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 30
periodSeconds: 30
volumeMounts:
- name: data
mountPath: /data
volumeClaimTemplates:
- metadata:
name: data
annotations:
volume.alpha.kubernetes.io/storage-class: default
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 300Gi
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
kubernetes.io/tls-acme: "true"
acme.cert-manager.io/http01-edit-in-place: "true"
labels:
app: drone
name: drone
spec:
backend:
serviceName: drone
servicePort: 80
tls:
- hosts:
- xxx
secretName: drone-drone-server-tls
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: drone
subjects:
- kind: ServiceAccount
# Reference to upper's `metadata.name`
name: default
# Reference to upper's `metadata.namespace`
namespace: drone
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1beta2
kind: Deployment
metadata:
name: kubernetes-secrets
labels:
app: kubernetes-secrets
spec:
replicas: 1
selector:
matchLabels:
app: kubernetes-secrets
template:
metadata:
labels:
app: kubernetes-secrets
spec:
containers:
- name: kubernetes-secrets
image: drone/kubernetes-secrets
imagePullPolicy: Always
env:
- name: KUBERNETES_NAMESPACE
value: drone
- name: DEBUG
value: "true"
- name: SECRET_KEY
valueFrom:
secretKeyRef:
name: vault-plugin-secret
key: secret
ports:
- name: http
containerPort: 3000
protocol: TCP
resources:
limits:
cpu: 500
memory: 768Mi
requests:
cpu: 100m
memory: 256Mi
---
apiVersion: v1
kind: Service
metadata:
name: kubernetes-secrets
labels:
app: kubernetes-secrets
spec:
type: ClusterIP
ports:
- port: 3000
targetPort: 3000
protocol: TCP
name: http
selector:
app: kubernetes-secretswhen you set DRONE_KUBERNETES_ENABLED=true you are enabling an experimental kubernetes integration that was deprecated some time ago. This deprecated integration does not recognize the type attribute. Instead you should install the kubernetes runner:
https://docs.drone.io/runner/kubernetes/overview/
Thank you for your help.
Any timeline for addressing this issue in kubernetis runner:
The pipeline status is not correctly passed to containers, impacting plugins that rely on this value. This primarily impacts notification plugins, such as Slack, which will always report the pipeline status as success.
also heads up that gtaylor put together some Helm charts that you can use as reference https://github.com/gtaylor/drone-charts
We should update the docs to clarify … the updated status is passed to the container, however, unlike the docker runner it is passed by file instead of environment variable. Existing plugins need to be patched to read this file. You can look at this patch to the Slack plugin where we source the environment file to get the updated status.
If there is a specific plugin that you are using from the plugins/* organization let us know, and we can make sure it is reading this file.
is DRONE_KUBERNETES_ENABLED=true deprecated?
I installed drone via helm chart
│ Environment:
│ DRONE_KUBERNETES_ENABLED: true
and this is present. Is there are any value I can set in the helm chart to not use deprecated behavior? I’ve read up about limitations.
is DRONE_KUBERNETES_ENABLED=true deprecated?
Yes, this flag enables an experimental feature that was deprecated and replaced by the kubernetes runner.
I installed drone via helm chart
The chart in helm stable is unofficial (we are not involved) and seems out of date and out of sync with the project and how it has evolved. For this reason we began publishing our own charts. See http://discuss.harness.io/t/official-helm-chart/6827
Is it possible to release the slack plugin with the patch ?
yes, I’ll tag a release tomorrow morning. In the meantime you can test with plugins/slack:latest
mmm, I tested the brand new drone and drone-runner-kube charts in a new cluster.
I carefully setup all the required parameters and I have 0 errors in logs, however builds does not start, they remain in pending state.
anything I can check?
found the issue: wrong type of pipeline definition in .drone.yml
Hi,
I was trying to use the chart and found that the DRONE_RPC_SECRET must be specified as a string, not supporting the secretKeyRef.
I would like to specify the secrets using the standard secret management facilities:
- name: DRONE_RPC_SECRET valueFrom: secretKeyRef: name: drone key: rpc-secret