Skip to content

CI/CD & Release Process

This page describes the GitHub Actions workflows that power Burrito's CI/CD pipeline and explains the step-by-step release process.

Workflows Overview

Workflow Trigger Purpose
ci.yaml Push / PR on main Run Go unit & integration tests
ci-frontend.yaml Push / PR on main Lint and build the UI
conventional-commits.yaml PR on main Enforce Conventional Commits format
build-and-push.yaml Reusable (called by others) Build multi-arch Docker images, push to GHCR, and sign the manifest with cosign
release.yaml workflow_dispatch Orchestrate a full release
tag-on-release.yaml Push to main (VERSION changed) Create git tag, push Helm chart, deploy docs
helm.yaml Reusable (called by others) Package, push, and sign the Helm chart on GHCR
docs.yaml Reusable (called by others) Deploy documentation with mike
trivy.yaml Scheduled / push Container image vulnerability scanning

Release Process

Releases are triggered manually via the release.yaml workflow with a version string (e.g. v1.2.3) as input.

Step-by-step

  1. Trigger — A maintainer runs the release workflow from GitHub Actions, providing the target version (must follow SemVer, prefixed with v).

  2. Build Docker images — The build-and-push.yaml reusable workflow builds platform-specific images for linux/amd64 and linux/arm64 in parallel, then merges them into a single multi-arch manifest pushed to ghcr.io/padok-team/burrito:<version>. The manifest is then signed with cosign (see Signing).

  3. Version bump PR — Once the images are published, the release workflow:

    • Updates the VERSION file with the new version.
    • Updates Chart.yaml (version and appVersion).
    • Pins the image tag and digest in values.yaml (both the main image and the runner image).
    • Commits those changes to a new branch bump-version-<version> and opens a pull request against main.
  4. PR review & merge — A maintainer reviews and merges the version bump PR into main.

  5. Tag creation — Merging the PR changes the VERSION file on main, which automatically triggers tag-on-release.yaml. This workflow reads the new version and creates a matching git tag (e.g. v1.2.3).

  6. Helm chart release — The helm.yaml workflow packages the Burrito Helm chart, pushes it to ghcr.io/padok-team/charts, and signs it with cosign.

  7. Documentation release — The docs.yaml workflow runs mike deploy <version> latest to publish the versioned documentation to GitHub Pages.

Diagram

flowchart TD
    A([Maintainer triggers\nrelease.yaml\nwith version input]) --> B

    subgraph release ["release.yaml (workflow_dispatch)"]
        B[Build Docker images\namd64 + arm64] --> C
        C[Merge multi-arch manifest\nPush to GHCR with version tag] --> C2
        C2[Sign manifest with cosign] --> D
        D[Bump VERSION, Chart.yaml\nPin image digest in values.yaml] --> E
        E[Open PR: bump-version-vX.Y.Z]
    end

    E --> F([PR reviewed & merged to main])

    F --> G

    subgraph tagging ["tag-on-release.yaml (VERSION changed on main)"]
        G[Read VERSION file] --> H
        H[Create & push git tag vX.Y.Z]
    end

    H --> I & J

    subgraph helm ["helm.yaml"]
        I[Package Helm chart\nPush to ghcr.io/padok-team/charts] --> I2
        I2[Sign chart with cosign]
    end

    subgraph docsw ["docs.yaml"]
        J[Deploy docs\nmike deploy vX.Y.Z latest]
    end

Image Tags

Each published Docker image receives the following tags:

  • <version> — e.g. v1.2.3
  • <git-sha> — full commit SHA for traceability
  • latest — only updated when merging to main

The image digest is also pinned in values.yaml to guarantee reproducible installs.

Signing

Every Docker image and Helm chart pushed to GHCR is signed with cosign using keyless (OIDC) signing — no private key material is stored or managed. The signature is bound to the GitHub Actions run that produced the artifact and is stored alongside it in GHCR.

Signing happens right after the artifact is pushed, by digest, in build-and-push.yaml (job merge) and helm.yaml (job helm-push). It requires the id-token: write permission, which every workflow calling these reusable workflows must grant.

To verify a signature:

# Docker image
cosign verify ghcr.io/padok-team/burrito:<version> \
  --certificate-identity-regexp 'https://github.com/padok-team/burrito/.github/workflows/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

# Helm chart
cosign verify ghcr.io/padok-team/charts/burrito:<chart-version> \
  --certificate-identity-regexp 'https://github.com/padok-team/burrito/.github/workflows/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com