We use GCP Cloud Build to package charts in this repo and push result to GCS bucket. Check How-to guides to cover common Cloud Build use cases. In this manual we explain our Cloud Build configuration step by step.
Helm can deploy releases into Kubernetes from file system or repositories. Common practice is to add external/remote chart repository into helm and use repo for deploys and updates. Thus we can build our charts once to be usable for everyone from chart repository, and we have a standard way to deliver updates - just push new chart version into the chart repo. Cloud Build, like other CI/CDs, offloads this part from developers to machines.
We use single Cloud Build manifest with substitutions to pack 2 charts - bitcoind and parity. Structure of our manifest is the following:
steps
. Build steps, package and push happens here. Files are passed between stepssubstitutions
. Variables with default values and override possibility during manual or automatically triggered buildsoptions
. Various build optionsartifacts
. Artifacts are used to upload build results such as binaries, archives, text files etc to some permanent storage or repository
Let's dive in:
We use in-project helm cloud builder image just to speed up builds due to smaller image. It's image from
GCP helm cloud builder, but gcloud-slim
-based.
You may use this manual
to build your own helm cloud builder image.
Here is steps description:
helm package
- install helm-gcs plugin to support GCS buckets as chart repository storage
- configure helm to use chart repository from substituted environment variables
- package chart to archive
add version plugin
. Install helm-local-chart-version pluginsave version to artifact
. Get chart version and save it to filehelm push
. Push packaged chart to chart repository and update repository metadata
_REGISTRY
base registry domain, useeu.gcr.io
to save bandwidth with EU deployments_ENV
environment we build chart for. Used with artifacts_CHART_NAME
bitcoind or parity_HELM_REPO_NAME
local name of chart repository_HELM_REPO_URL
chart repository URL we push packaged chart to_ARTIFACT_URL
GCS bucket path Cloud Build uploads artifacts to on success_ARTIFACT_FILENAME
file name to store latest build chart version
env
varSKIP_CLUSTER_CONFIG
is required by helm cloud builder to skip configuration of kubectl context. It's added to every step. Thus you don't require working GKE cluster in the project where you want to run builds from this cloudbuild manifest.
location
- path where Cloud Build uploads artifacts on success. We use_ENV
as a path part to store artifacts for environments separatelypaths
- path list of files/directories to upload. We store single file with chart version only
-
Please meet the requirements from this readme
-
Activate Cloud Build API on GCP side:
export GCP_PROJECT_ID=$(gcloud config get-value project) gcloud services enable cloudbuild.googleapis.com --project=${GCP_PROJECT_ID}
-
Create GCS buckets to store chart repository and artifacts. We use single bucket in this manual to store both.
export HELM_REPO_BUCKET=${GCP_PROJECT_ID}-helm-repo gsutil mb -p ${GCP_PROJECT_ID} -c standard gs://${HELM_REPO_BUCKET} export HELM_REPO_URL=gs://${HELM_REPO_BUCKET}/charts/ export ARTIFACT_URL=gs://${HELM_REPO_BUCKET}/versions/
-
Build GCP helm cloud builder to have this builder image in your project
-
Install helm-gcs plugin
# 0.2.2 is the last version with helm 2 support helm plugin install https://github.com/hayorov/helm-gcs --version 0.2.2
-
Init chart repository in GCS bucket. We have to do it once per every new chart repository
helm gcs init ${HELM_REPO_URL}
-
Clone this git repo and change dir to the cloned repo root
-
Run Cloud Build. We build
parity
chart in this example:gcloud builds submit --config=cloudbuild.yaml . --project=${GCP_PROJECT_ID} --substitutions=_HELM_REPO_URL=${HELM_REPO_URL},_ARTIFACT_URL=${ARTIFACT_URL},_CHART_NAME=parity,_ARTIFACT_FILENAME=parity-chart-version
Check console output for
REMOTE BUILD OUTPUT
, it may take some time to finish. You may hit errors during build, here are some examples:- "not a valid chart repository"
It looks like init of GCS chart repo failed/wasn't performed on path specified in the error text. Retry chart repo init, check repo paths match.
Step #0 - "helm package": Error: Looks like "gs://..." is not a valid chart repository or cannot be reached: plugin "scripts/pull.sh" exited with error Finished Step #0 - "helm package" ERROR
- "chart already indexed"
It means that you have this chart version in the repo already. Increasing chart version in
Step #3 - "helm push": chart parity-0.1.38 already indexed. Use --force to still upload the chart Step #3 - "helm push": Error: plugin "gcs" exited with error Finished Step #3 - "helm push" ERROR ERROR: build step 3 "gcr.io/.../helm" failed: exit status 1
Chart.yaml
file atversion:
line is the recommended way to solve this. Then rerungcloud builds ...
again.
You may get further support here
- "not a valid chart repository"
Usually you need to trigger Cloud Build on every push to your Github repo. Take a note - Cloud Build is a paid service, check pricing before proceed.
Use official docs to configure triggers, Github triggers specially. We just emphasize key points:
- create one trigger per resulting chart
- use
Included files filter (glob)
, for examplecharts/bitcoind/**
for bitcoind chart to trigger corresponding build when related files are changed only. - specify
Substitution variables
, at least_HELM_REPO_URL
_ARTIFACT_URL
_CHART_NAME
_ARTIFACT_FILENAME
You may need to cleanup staff after you've stopped to use Cloud Build. Here is a check list:
- helm cloud builder images in container registry inside your project
- chart repo and artifacts in GCS bucket(s)
- "<project_name>_cloudbuild" GCS bucket to store code for manual Cloud Build submits
- Cloud Build trigger(s) and/or connected repositories