woodpecker-ci / helm Goto Github PK
View Code? Open in Web Editor NEWThis repo contains the helm charts of the Woodpecker project.
License: Apache License 2.0
This repo contains the helm charts of the Woodpecker project.
License: Apache License 2.0
The helm chart currently requires manual creation of secrets, copying env vars, and knowing which options clash (i.e. 2 Forges simultaneously)
Switching the woodpecker-server chart from "copy these env into your file" to just "set gitlab, gitea, github or whatever to true and add the values defined in the respective section".
This would mean providing simple settings in the values.yaml, possibly verifying those settings, and therefore abstracting the actual configuration from the user.
Implementing this would allow us to change parameters, option orders, etc. in the non-user facing part and therefore providing a hands-off upgrade approach on the chart based installations.
In this case it is pretty much do it, or document it. Documentation might be useful, but does not solve the problem of issues / support effort when users upgrade in a breaking way
It might not be strictly necessary, but I would be open to implement it.
The Helm chart has tag: ""
which Helm would fallback to appVersion
, which currently resolves to 1.0.2
. Unfortunately, on Docker Hub, the image is actually v1.0.2
โ so I had to override the tag in values.yaml
.
The obvious solution(s) to me are:
v
in Helm chartv1.0.2
and 1.0.2
to Docker HubI'm happy to contribute (1) if maintainers are OK with it, but if I were the maintainers, I probably would consider doing (2) just to remove possible edge cases for end user.
What do you think? ๐
When enabling it, runs triggered in the UI are "pending forever" and are somehow not sent to the agents properly. It seems only one server pod is able to do that and if a user gets a session with the other one, the behavior described above occurs.
I am not meaning to infer it should work, just noting it down for visibility etc.
Killing a "wrong" pod and getting assigned a new session with the "correct" one will let subsequent restarts be triggered successfully.
I just started playing around with woodpecker on Kubernetes (k3s in my case).
However even without any user-provided values the current chart version leads to failing pods in my tests:
$ helm install woodpecker woodpecker/woodpecker
[...]
$ kubectl logs woodpecker-server-0
{"level":"info","time":"2024-06-18T08:37:45Z","message":"log level: info"}
{"level":"fatal","error":"can't setup globals: could not setup service manager: forge not configured","time":"2024-06-18T08:37:45Z","message":"error running server"}
$
Is there something that I need to prepare before installation? If so, that step is missing in the README (or I have completely missed it)...
Kind Regards,
Johannes
1.2.1
from https://woodpecker-ci.org/
woodpecker.agent.persistence.enabled
to false
While using defaults with agent persistence of 1GiB works fine out-of-the-box, trying to disable agent persistence results in an invalid StatefulSet, not spawning any agent pods and failing with the following error:
Warning FailedCreate 3m3s (x17 over 8m31s) statefulset-controller create Pod woodpecker-agent-0 in StatefulSet woodpecker-agent failed error: Pod "woodpecker-agent-0" is invalid: spec.containers[1].image: Required value`
See screenshot for comparison between default agent persistence and disabling agent persistence.
This is a result of the If-statement here https://github.com/woodpecker-ci/helm/blob/main/charts/woodpecker/charts/agent/templates/statefulset.yaml#L109 and especially the If-Else-statement further down here https://github.com/woodpecker-ci/helm/blob/main/charts/woodpecker/charts/agent/templates/statefulset.yaml#L133
I don't quite get what the point of the If-Else-statement is in the first place, since there won't be a volume mount at all, when agent persistence is disabled.
The default policy for image pull should be IfNotPresent
instead of Always
to avoid hitting public rate limiting on docker.io.
Always
must only be used with a dockerhub account and/or the tag next or latest.
I submitted 2 PR recently (after May 24th).
The CI that does pre-checks fails for some reasons I don't understand.
I can't find any CI success since May 24th.
If the CI is really broken, could you please repair it ?
If the CI is working, could you please review the following runs (and their PR) and explain what is wrong ?
Thanks in advance
Such as https://github.com/helm-unittest/helm-unittest?
We use it in the Gitea helm chart and I think it's good to have it. Better earlier than late, so unit tests could be a requirement for new template additions/changes.
helm-docs (https://github.com/norwoodj/helm-docs) generates a pretty README.md that is templatizable.
Of course, there is a docker image.
Kept from https://github.com/argoproj/argo-helm/
#!/bin/bash
## Reference: https://github.com/norwoodj/helm-docs
set -eux
REPO_ROOT="$(cd "$(dirname "$0")/.." && pwd)"
echo "$REPO_ROOT"
echo "Running Helm-Docs"
docker run \
-v "$REPO_ROOT:/helm-docs" \
-u $(id -u) \
jnorwood/helm-docs:v1.11.0
server
The helm chart for the woodpecker-server supports the "existingClaim" option under persistentVolume, but the values.yml does not include the option.
The option is required if you want to use an existing PersistentVolumeClaim.
persistentVolume
enabled: true
## Name of an existing PVC
# existingClaim:
Helm chart 0.15.x
No response
In Kubernetes, a pod that needs a PersistentVolumeClaim object with accessModes ReadWriteOnce specification is deployed via a StatefulSet.
Convert actual woodpecker-server Deployment into a StatefulSet object.
PS - Let me know if you want a PR.
The ability to configure the accessModes of the PersistentVolumeClaim but I think it's a bad idea for example in a use case with the SSL and Let's Encrypt feature that stores the certificates in /var/lib/woodpecker/golang-autocert
.
An other use case would be a accidental scale to 2 replicas with sqlite backend : keeping the accessModes to ReadWriteOnce will avoid simultaneous access to the db file by two woodpecker-server processes.
No response
Only the agent needs a serviceAccount to link the specific RBAC.
Well, the serviceAccount of the server component can be disabled by default.
After the latest upgrade to 1.1 charts I got can't setup store: could not open datastore: no value matched key
I follow a GitOps approach (using ArgoCD) and never have secrets in a values.yaml by using SealedSecrets operator currently.
When I upgraded from the 1.0.x chart to the 1.1. Chart, the secret generated by the SealedSecrets operator was overwritten, caused by #144.
I now had to set the secrets for agent and server to both:
secrets: {}
so the SealedSecrets operator was able to create the decrypted secrets.
This secret generation wasn't as obvious as I thought because I missed or, to be more precise, dismissed it in the changelog because I had set createSecret: false
previously, thinking that hadn't been changed.
I don't know, but the current solution will cause some issues for users using argocd or fluxcd with secret solutions like vault, sealed-secrets or sops (often in combination with fluxcd). Maybe this should be documented somehow?
The docs reference the chart being published as an OCI artifact: oci://registry-1.docker.io/woodpeckerci/helm
but there's nothing there at the moment: https://hub.docker.com/r/woodpeckerci/helm/tags
From what I can see in .woodpecker/release.yaml
, there's no helm push
.
Here's an example from a GHA workflow: https://github.com/prometheus-community/helm-charts/blob/ef3fe76dbb88ce712eaae22e8e14a868d41df061/.github/workflows/release.yaml#L53-L61
shopt -s nullglob
for pkg in .cr-release-packages/*; do
if [ -z "${pkg:-}" ]; then
break
fi
helm push "${pkg}" "oci://ghcr.io/${GITHUB_REPOSITORY_OWNER}/charts"
done
When showing off woodpecker it would be nice to say it's only one helm install away (possibly even with a optional Gitea instance).
especially when working with "custom" tags (i.e. pull_XXXX, next- once that becomes a thing), keeping the agent and server in sync is benificcial if not required.
Just do some nice docs helping towards an easy setup for non-versed users (be it Kubernetes, helm or woodpecker itself)
It's just a nice to have, but would probably be a good addition after #4 is done.
Great to have a dedicated helm repo now!
I would be eager to test HEAD on k8s and report how it goes. Waiting for some installation instructions, specifically how to switch between HEAD/release :)
1.2.0
or higher from https://woodpecker-ci.org/
woopecker.agent.prersistence.enabled
to true
woodpecker.agent.extraVolumes
and woodpecker.agent.extraVolumeMounts
When woodpecker.agent.extraVolumes
and woodpecker.agent.extraVolumeMounts
are configured, and woodpecker.agent.persistence
is set to true
, an error occurs when parsing the helm templates.
Error: YAML parse error on woodpecker/charts/woodpecker/charts/agent/templates/statefulset.yaml: error converting YAML to JSON: yaml: line 42: did not find expected '-' indicator
helm.go:84: [debug] error converting YAML to JSON: yaml: line 42: did not find expected '-' indicator
YAML parse error on woodpecker/charts/woodpecker/charts/agent/templates/statefulset.yaml
woodpecker:
agent:
enabled: true
replicaCount: 2
image:
tag: v2.4.1-alpine
persistence:
enabled: true
extraVolumes:
- name: ca-pemstore
configMap:
name: ca-pemstore
extraVolumeMounts:
- name: ca-pemstore
mountPath: /etc/ssl/certs/CustomCA.pem
subPath: CustomCA.pem
extraSecretNamesForEnvFrom:
- agent-env
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
These updates are awaiting their schedule. Click on a checkbox to get an update now.
charts/woodpecker/charts/agent/values.yaml
charts/woodpecker/charts/server/values.yaml
charts/woodpecker/values.yaml
charts/woodpecker/Chart.yaml
.woodpecker/test.yml
helm-unittest/helm-unittest v0.5.2
charts/woodpecker/Chart.yaml
woodpecker-ci/woodpecker 2.7.0
charts/woodpecker/charts/agent/Chart.yaml
woodpecker-ci/woodpecker 2.7.0
charts/woodpecker/charts/server/Chart.yaml
woodpecker-ci/woodpecker 2.7.0
.woodpecker/release-helper.yml
woodpeckerci/plugin-ready-release-go 1.2.0
.woodpecker/release.yml
quay.io/helmpack/chart-releaser v1.6.1
quay.io/helmpack/chart-releaser v1.6.1
jnorwood/helm-docs v1.14.2
appleboy/drone-git-push 1.1.0
.woodpecker/test.yml
alpine/helm 3.15.4
alpine/helm 3.15.4
quay.io/helmpack/chart-testing v3.11.0
I used the helm chart to deploy woodpecker server and agent.
With `WOODPECKER_BACKEND_K8S_STORAGE_CLASS: "nfs-rwx-storage"`` which is RWX storage class, the clone step unusually takes long time (~2m) to complete. When I disable RWX, it take less than 20s to get completed.
I can see it logs, volume mount is immediateltly available to the build pod:
Has any one experienced this? Any way to disable volume mounting?
Hello there. I am experimenting with this project for a friend who wants to use it in their business, and might end up using it myself, we'll see.
During the deployment, I encountered the following issues:
Even if you don't fix this, at least leave this issue open for people to find quick answers to their problem if they encounter the same one.
I got it working here:
HelmRelease
Permalink
Granted, I haven't tested any pipelines, but everything turned on and the webpage loaded, so it probably works.
Thanks for the project!
so that make readme
works. This should also be linted in CI
Hi,
congrats to https://github.com/woodpecker-ci/helm/releases/tag/1.1.0 release. Sadly I have issues updating it in my k3s system. I use k3s helm-controller, however following definition fails
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
name: woodpecker
namespace: woodpecker
spec:
version: 1.1.0
chart: woodpecker
repo: https://woodpecker-ci.org/
targetNamespace: woodpecker
When running helm locally all I see is 1.0.3
$ helm repo list
NAME URL
...
woodpecker https://woodpecker-ci.org/
$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "woodpecker" chart repository
Update Complete. โHappy Helming!โ
$ helm search repo woodpecker --versions
NAME CHART VERSION APP VERSION DESCRIPTION
woodpecker/woodpecker 1.0.3 2.1.1 A Helm chart for Woodpecker CI
woodpecker/woodpecker 1.0.2 2.1.0 A Helm chart for Woodpecker CI
...
BTW: noticed the artifactory lists 1.0.3 as the last version too https://artifacthub.io/api/v1/packages/helm/woodpecker-ci/woodpecker/feed/rss
Deploying from tf. It would be nice if the secret creation was optional, so the chart worked out of the box. I think the secret references in the .values should likely just be a comment.
Alternatively it could be optionally created:
{{- if .Values.createSecret }}
apiVersion: v1
kind: Secret
metadata:
name: {{ .Values.secretName }}
type: Opaque
{{- end }}
Could also be a pre chart hook to create if not present:
apiVersion: batch/v1
kind: Job
metadata:
name: pre-install-secret-check
annotations:
"helm.sh/hook": pre-install
spec:
template:
spec:
containers:
- name: check-secret
image: appropriate-image
command: ["/bin/sh"]
args: ["-c", "upsert_secret.sh"]
restartPolicy: OnFailure
server
The default kubernetes helm deployment enables the github integration from woodpecker. But woodpecker can be used in scenarios without github integration. If someone does not want the github integration, it must be actively disabled.
My proposal is, to remove the github configs from the helm charts values.yml
env:
WOODPECKER_GITHUB: true
extraSecretNamesForEnvFrom:
- woodpecker-github-client
- woodpecker-github-secret
With this change the documentation also needs to be adjusted.
Helm chart for 0.15.x
No response
The CI complains about the missing templates directory in the 'lint' step.
Since the last PR on the server, it is possible to configure the labels, annotations and the number of history of the statefullSet. The goal is to standardize the agent deployment.
PS - I will do a PR in a few days.
I am using the helm chart and the docs to get started on k3s. Following the docs, I have changed server.persistentVolume.storageClass
to local-path
. The server is stuck at pending with 1 pod has unbound immediate PersistentVolumeClaims
. I have futilely tried to create a persistent volume manually. Admittedly, I am pretty new to the k8s ecosystem, and I might have missed some simple step.
agent:
# -- The number of replicas for the deployment
replicaCount: 1
image:
# -- Overrides the image tag whose default is the chart appVersion.
tag: ""
env:
# -- Add the environment variables for the agent component
WOODPECKER_BACKEND_K8S_VOLUME_SIZE: 5G
server:
image:
tag: ""
# -- Add environment variables for the server component
env:
WOODPECKER_ADMIN: "aphilas"
WOODPECKER_HOST: "https://ci.example.org"
WOODPECKER_GITHUB: "true"
persistentVolume:
# -- Defines the size of the persistent volume
size: 5Gi
# -- Defines the storageClass of the persistent volume
storageClass: "local-path"
# -- Defines the path where the volume should be mounted
# mountPath: "/var/lib/woodpecker"
mountPath: null
service:
# -- The port of the service
port: &servicePort 80
ingress:
# -- Enable the ingress for the server component
enabled: true
# -- Add annotations to the ingress
annotations:
kubernetes.io/ingress.class: traefik
cert-manager.io/cluster-issuer: letsencrypt-prod
traefik.ingress.kubernetes.io/router.middlewares: default-redirect-https@kubernetescrd
hosts:
- host: ci.example.org
paths:
- path: /
backend:
serviceName: ci.example.org
servicePort: *servicePort
tls:
- secretName: woodpecker-tls
hosts:
- ci.example.org
helm upgrade --install -f myvalues.yml woodpecker-server woodpecker/woodpecker-server
In the case of using litestream when the server uses the sqlite database, we should be able to add a initContainer and a sidecar on the server component.
https://litestream.io/guides/kubernetes/
PS - I will do a PR in a few days.
The latest release of helm is v3.11.1 and it's available with apline image base:
alpine/helm:3.11.1
With NEXT (woodpecker-agent@sha256:6a625b1a1b40f7f840a3a4da7230f45735232fa14b45402bcad10b27a7faf8c3) ) I get on a fresh deployment
woodpecker-agent 10:43PM WRN cancel signal received error="rpc error: code = Unknown desc = Step finished with exitcode 1, persistentvolumeclaims is forbidden: โ
โ User \"system:serviceaccount:woodpecker-agent:woodpecker-agent\" cannot create resource \"persistentvolumeclaims\" in API group \"\" in the namespace \"woodpeck โ
โ er-agent\""
with
env:
WOODPECKER_SERVER: woodpecker-server.woodpecker-server.svc.cluster.local:9000
WOODPECKER_BACKEND_K8S_NAMESPACE: woodpecker-agent
WOODPECKER_BACKEND_K8S_STORAGE_CLASS: ebs-sc
WOODPECKER_BACKEND: kubernetes
WOODPECKER_BACKEND_K8S_STORAGE_RWX: false
I'd expect here that the serviceaccount created would have the required scopes to create the PVC.
Hi, the problem as as the title states. The Helm chart version is 1.5.0, the latest as of this moment.
The agent pod crashes. Upon inspecting the the logs of the agent pod state:
{"level":"info","time":"2024-07-18T17:33:24Z","message":"log level: info"}
{"level":"info","time":"2024-07-18T17:33:24Z","message":"no agent config found at '/etc/woodpecker/agent.conf', start with defaults"}
{"level":"fatal","error":"rpc error: code = Unknown desc = agent could not auth: please provide a token","time":"2024-07-18T17:33:24Z","message":"error running agent"}
It looks like the secret isn't being loaded.
The following is my Helm for the agent section of values.yml
:
agent:
enabled: true
env:
WOODPECKER_BACKEND_K8S_NAMESPACE: [...]
WOODPECKER_BACKEND_K8S_STORAGE_CLASS: "standard"
persistence:
storageClass: "standard"
size: "10Gi"
replicaCount: 1
Looking at the environment variable section of kubectl describe
ing the agent:
Environment Variables from:
woodpecker-secret Secret Optional: false
Environment:
WOODPECKER_BACKEND: kubernetes
WOODPECKER_BACKEND_K8S_NAMESPACE: [...]
WOODPECKER_BACKEND_K8S_POD_ANNOTATIONS:
WOODPECKER_BACKEND_K8S_POD_LABELS:
WOODPECKER_BACKEND_K8S_STORAGE_CLASS: standard
WOODPECKER_BACKEND_K8S_STORAGE_RWX: true
WOODPECKER_BACKEND_K8S_VOLUME_SIZE: 10G
WOODPECKER_CONNECT_RETRY_COUNT: 1
I believe there should be a WOODPECKER_AGENT_SECRET
environment variable, but I don't see one.
I may be configuring something incorrectly. Any help would be greatly appreciated.
rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp: lookup woodpecker-server..svc.cluster.local: no such host"
Agent configuration https://woodpecker-ci.org/docs/administration/agent-config#using-system-token says
the agent registers to the server and store its unique id in a config file
Sadly this does not work well in k8s. The installed agents complaints about and as a consequence the list of registered agents grows all the time and I need to manually clean it up from time to time.
{"level":"error","error":"open /etc/woodpecker/agent.conf: no such file or directory","time":"2024-01-13T01:28:47Z","message":"could not persist agent config at '/etc/woodpecker/agent.conf'"}
Is it possible to address that somehow in helm? I am not an expert, so I have no idea if this is possible to do or if that require code changes.
Must be a valid semantic version tag like 1.0.0.
helm repo add woodpecker-agent-git "git+https://github.com/woodpecker-ci/helm@woodpecker-agent?ref=main&sparse=1"
./helm-git-plugin.sh: line 113: .git/info/sparse-checkout: No such file or directory
Error: validation: chart.metadata.version "<version>" is invalid
Error: looks like "git+https://github.com/woodpecker-ci/helm@woodpecker-agent?ref=main&sparse=1" is not a valid chart repository or cannot be reached: plugin "helm-git" exited with error
I need to configure the server service as a loadBalancer service.
I can write server.service.type: LoadBalancer
.
But there is nowhere to specify the IP (with loadBalancerIP
).
I submitted PR #48 as a fix for this issue.
woodpecker-ci/woodpecker#1728 adds retry ... but on k8s it should be handle by the carts itself ;)
I'm trying to make a container registry config available as described here. The easiest way I can see to do that would be to mount a Secret containing the docker config file and then set the WOODPECKER_DOCKER_CONFIG
to match the path where I mounted the file. However, I can't seem to find a good way to mount the config file in the server container.
Maybe we could add extraVolumeMounts:
and extraVolumes:
to the server values?
it would be nice, that this helmcharts deploy also a ServiceMonitor, which select all Service (and there behind all Pods) to scrape all Metrics.
https://prometheus-operator.dev/docs/operator/api/#monitoring.coreos.com/v1.ServiceMonitor
Pod that should execute a job got
Node-Selectors: kubernetes.io/arch=amd64
while nodes in GKE with Kubernetes version: v1.26.6-gke.1700 are labeled beta.kubernetes.io/arch=amd64
.woodpecker.yml
pipeline:
dummy-job:
image: busybox
commands:
- echo "Dummy pipeline"
backend_options:
kubernetes:
nodeSelector:
beta.kubernetes.io/arch: amd64
values.yaml
agent:
image:
tag: "v1.0.0"
env:
WOODPECKER_AGENT_SECRET: "aaaaaaa"
WOODPECKER_SERVER: "woodpecker-server.woodpecker.svc.cluster.local:9000"
WOODPECKER_BACKEND: kubernetes
WOODPECKER_BACKEND_K8S_NAMESPACE: woodpecker
nodeSelector:
beta.kubernetes.io/arch: amd64
In the documentation is mentioned:
Labels defined here will be appended to a list already containing "kubernetes.io/arch". By default the pod will use "kubernetes.io/arch" inferred from top-level "platform" setting which is deducted from the agents' environment variable CI_SYSTEM_PLATFORM. To overwrite this, you need to specify this label in the nodeSelector section.
The question is how to remove that default label, and add beta.kubernetes.io/arch=amd64
We have added a .cr-index/indey.yaml
with the release push somehow which seems to be not needed and should be removed and ignored: b3e9773
I'm struggling a bit to understand the proper method to install this chart. From the docs it seems like we should install from the helm repo at https://woodpecker-ci.org/. The "next" branch docs don't give specific install instructions (they just link to this repo). But, this is what I'm seeing:
$ helm repo add woodpecker https://woodpecker-ci.org
"woodpecker" has been added to your repositories
$ helm search repo woodpecker
NAME CHART VERSION APP VERSION DESCRIPTION
woodpecker/woodpecker 0.1.5 v0.15.9 A Helm chart for Woodpecker CI
It looks like the most recent version available is 0.1.5, but on GitHub I see a 0.3.0 release from a couple of days ago. Is there another repo where the more recent releases are available? I apologize for the basic question. I'm still fairly new to helm, and I might be missing something very obvious.
This might be related to #45, but I'm not sure.
It seems that init containers are not supported/exposed, they should be.
The server chart should expose way to specify initContainers in values.
the current version over woodpecker-server has no stateful-set yet.
does the CI-Pipeline works like expacted?
Originally posted by @genofire in #94 (comment)
This is a follow up from #97. In my testing, it looks like the extra volume mounts are added at the wrong indent level which breaks the YAML and the entire chart. If I run helm template ...
I get YAML that looks like this:
# Source: woodpecker/charts/server/templates/statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: woodpecker-server
spec:
serviceName: woodpecker-server-headless
template:
spec:
serviceAccountName: default
securityContext:
{}
containers:
- name: server
securityContext:
{}
image: "docker.io/woodpeckerci/woodpecker-server:next"
imagePullPolicy: IfNotPresent
resources:
{}
volumeMounts:
- name: data
mountPath: /var/lib/woodpecker
- mountPath: /etc/registry
name: reg-cred
readOnly: true
env:
- name: ...
I removed some irrelevant parts for clarity. You can see that the mountPath
stanza is indented a bit too far.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.