|
| 1 | +# Chainloop Build and Packaging Overview |
| 2 | + |
| 3 | +## Release Flow |
| 4 | + |
| 5 | +The release process starts by pushing a **git tag** matching `v*.*.*`, which triggers the `release.yaml` GitHub Actions workflow. |
| 6 | + |
| 7 | +``` |
| 8 | +Tag push (v1.x.x) → Tests → GoReleaser build → Signing → Helm chart bump PR |
| 9 | +``` |
| 10 | + |
| 11 | +## Building with GoReleaser |
| 12 | + |
| 13 | +All binaries and container images are built via [GoReleaser](https://goreleaser.com/) (`.goreleaser.yml` at the repo root). |
| 14 | + |
| 15 | +### Binaries |
| 16 | + |
| 17 | +| Binary | Platforms | Notes | |
| 18 | +|--------|-----------|-------| |
| 19 | +| `control-plane` | linux/amd64, linux/arm64 | Main backend service | |
| 20 | +| `artifact-cas` | linux/amd64, linux/arm64 | Content-addressable storage proxy | |
| 21 | +| `chainloop` (CLI) | darwin/amd64, darwin/arm64, linux/amd64, linux/arm64 | Multi-platform client | |
| 22 | +| `chainloop-plugin-discord-webhook` | linux/amd64 | Bundled into control-plane image | |
| 23 | +| `chainloop-plugin-smtp` | linux/amd64 | Bundled into control-plane image | |
| 24 | +| `chainloop-plugin-dependency-track` | linux/amd64 | Bundled into control-plane image | |
| 25 | + |
| 26 | +All binaries are statically compiled (`CGO_ENABLED=0`) and stripped (`-s -w`). Version info is injected via `-ldflags` from the git tag. CLI binaries are published as GitHub Release assets alongside a `checksums.txt`. |
| 27 | + |
| 28 | +### Container Images |
| 29 | + |
| 30 | +GoReleaser uses **Docker buildx with QEMU** to produce multi-architecture images (amd64 + arm64), published to **GitHub Container Registry** (`ghcr.io/chainloop-dev/chainloop/`). |
| 31 | + |
| 32 | +| Image | Base | Dockerfile | |
| 33 | +|-------|------|------------| |
| 34 | +| `control-plane` | `scratch` | `app/controlplane/Dockerfile.goreleaser` | |
| 35 | +| `control-plane-migrations` | `arigaio/atlas` | `app/controlplane/Dockerfile.migrations` | |
| 36 | +| `artifact-cas` | `scratch` | `app/artifact-cas/Dockerfile.goreleaser` | |
| 37 | +| `cli` | `scratch` | `app/cli/Dockerfile.goreleaser` | |
| 38 | + |
| 39 | +**Tagging strategy:** |
| 40 | +- Platform-specific: `<image>:<tag>-amd64`, `<image>:<tag>-arm64` |
| 41 | +- Unified manifest: `<image>:<tag>` and `<image>:latest` |
| 42 | + |
| 43 | +### Signing |
| 44 | + |
| 45 | +All container images and release artifacts are signed with **Cosign** using a private key. |
| 46 | + |
| 47 | +## Building Dependency Container Images |
| 48 | + |
| 49 | +We don't consume upstream Bitnami container images directly. Instead, we **rebuild them from source** using the Dockerfiles in the [bitnami/containers](https://github.com/bitnami/containers) repository. This gives us full control over the build process, allows us to sign images with our own key, and host them in our own registry. |
| 50 | + |
| 51 | +This is handled by the **`build_external_container_images.yaml`** workflow, triggered manually via `workflow_dispatch`. |
| 52 | + |
| 53 | +### How it works |
| 54 | + |
| 55 | +1. The workflow checks out the `bitnami/containers` repo at a **pinned commit SHA** for reproducibility. |
| 56 | +2. Builds each image for **linux/amd64 + linux/arm64** using Docker buildx. |
| 57 | +3. Pushes to GHCR under `ghcr.io/chainloop-dev/chainloop/`. |
| 58 | +4. Signs the resulting image with Cosign. |
| 59 | + |
| 60 | +### Images built |
| 61 | + |
| 62 | +| Image | Version | Bitnami Source Path | |
| 63 | +|-------|---------|---------------------| |
| 64 | +| `postgresql` | 16.4.0 | `bitnami/postgresql/16/debian-12` | |
| 65 | +| `postgres-exporter` | 0.15.0 | `bitnami/postgres-exporter/0/debian-12` | |
| 66 | +| `os-shell` | 12 | `bitnami/os-shell/12/debian-12` | |
| 67 | +| `dex` | 2.43.1 | `bitnami/dex/2/debian-12` | |
| 68 | +| `vault` | 1.17.3 | `bitnami/vault/1/debian-12` | |
| 69 | +| `vault-csi-provider` | 1.4.3 | `bitnami/vault-csi-provider/1/debian-12` | |
| 70 | +| `vault-k8s` | 1.4.2 | `bitnami/vault-k8s/1/debian-12` | |
| 71 | +| `nginx-ingress-controller` | 1.12.1 | `bitnami/nginx-ingress-controller/1/debian-12` | |
| 72 | +| `nginx` | 1.27.4 | `bitnami/nginx/1.27/debian-12` | |
| 73 | + |
| 74 | +Each image is tagged with its app version, `latest`, and the git SHA. |
| 75 | + |
| 76 | +## Helm Chart |
| 77 | + |
| 78 | +### Location |
| 79 | + |
| 80 | +The main Helm chart lives at **`deployment/chainloop/`**. |
| 81 | + |
| 82 | +### Dependencies |
| 83 | + |
| 84 | +Sub-charts are **vendored** (committed under `deployment/chainloop/charts/`) as `file://` dependencies: |
| 85 | + |
| 86 | +| Sub-chart | Source | Condition | |
| 87 | +|-----------|--------|-----------| |
| 88 | +| `common` | Bitnami Common | Always (template utilities) | |
| 89 | +| `postgresql` | Bitnami PostgreSQL | `postgresql.enabled` | |
| 90 | +| `vault` | Bitnami Vault | `development` flag | |
| 91 | +| `dex` | Custom | `development` flag | |
| 92 | + |
| 93 | +All sub-chart container image references point to our own GHCR rebuilds (e.g., `ghcr.io/chainloop-dev/chainloop/postgresql:16.4.0`), not upstream Bitnami or Docker Hub. |
| 94 | + |
| 95 | +### Chart Bumping on Release |
| 96 | + |
| 97 | +After a successful release, the workflow creates a **PR** that: |
| 98 | + |
| 99 | +1. Bumps `appVersion` to the new tag (e.g., `v1.79.1`). |
| 100 | +2. Increments the chart version. |
| 101 | +3. Updates image tag references in `values.yaml`. |
| 102 | + |
| 103 | +This is handled by `.github/workflows/utils/bump-chart-and-dagger-version.sh`. |
| 104 | + |
| 105 | +## Local Development Builds |
| 106 | + |
| 107 | +```bash |
| 108 | +# Build binaries only (snapshot, current platform) |
| 109 | +make build_devel |
| 110 | + |
| 111 | +# Build binaries + container images locally (no signing) |
| 112 | +make build_devel_container_images |
| 113 | +``` |
0 commit comments