feat(github-action): build and publish container images#562
feat(github-action): build and publish container images#562knechtionscoding wants to merge 7 commits intouber:masterfrom
Conversation
|
|
There was a problem hiding this comment.
Pull request overview
Adds a GitHub Actions workflow to build and publish the project’s container images to GitHub Container Registry (GHCR), addressing the need for publicly available images for downstream deployments (e.g., Helm users).
Changes:
- Introduces a
publish-imagesworkflow that builds/pushes multi-arch images (amd64/arm64) for multiple Kraken components. - Uses Docker metadata-action to generate tags for branch, tag, and short SHA refs.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated 8 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated 9 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| images: ghcr.io/${{ github.repository_owner }}/${{ matrix.component }} | ||
| tags: | |
There was a problem hiding this comment.
Image naming uses only ${{ github.repository_owner }} (e.g., ghcr.io/uber/kraken-agent). That can collide if the owner publishes similarly named images from other repos. Consider including the repository in the path (e.g., ${{ github.repository }}) to make the namespace unambiguous.
There was a problem hiding this comment.
@Anton-Kalpakchiev Do you want repo to be included in here?
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| FROM golang:1.23.11 AS builder | ||
|
|
||
|
|
||
| ENV CGO_ENABLED=1 GO111MODULE=on | ||
|
|
||
| WORKDIR /src | ||
|
|
||
| RUN apt-get update && \ | ||
| apt-get install -y --no-install-recommends build-essential pkg-config sqlite3 libsqlite3-dev && \ | ||
| rm -rf /var/lib/apt/lists/* | ||
|
|
||
| COPY go.mod go.sum ./ | ||
| RUN go mod download | ||
|
|
||
| COPY . . | ||
| RUN mkdir -p /out && \ | ||
| go build -buildvcs=false -o /out/kraken-agent ./agent | ||
|
|
||
| FROM debian:12 |
There was a problem hiding this comment.
CGO_ENABLED=1 plus installing libsqlite3-dev strongly suggests the built binary may be dynamically linked against libsqlite3.so.*. The runtime stage (debian:12) does not install the runtime SQLite library, so the container can fail at startup with missing shared library errors. Fix by either (a) installing the runtime package (typically libsqlite3-0) in the final stage, or (b) building a fully static binary (e.g., use CGO_ENABLED=0 if the project supports it).
| RUN go mod download | ||
|
|
||
| COPY . . | ||
| RUN mkdir -p /out && \ |
There was a problem hiding this comment.
The builder stage doesn’t take advantage of BuildKit caching for Go modules/build cache, so CI builds will repeatedly download modules and recompile from scratch. Since you already set # syntax=docker/dockerfile:1.6, consider using BuildKit cache mounts for /go/pkg/mod and the Go build cache to significantly speed up repeated builds.
| RUN go mod download | |
| COPY . . | |
| RUN mkdir -p /out && \ | |
| RUN --mount=type=cache,target=/go/pkg/mod \ | |
| go mod download | |
| COPY . . | |
| RUN --mount=type=cache,target=/go/pkg/mod \ | |
| --mount=type=cache,target=/root/.cache/go-build \ | |
| mkdir -p /out && \ |
Resolves: #561 and publishes images to the ghcr registry for the repo.
This allows people to use the images without forking/cloning the repo
Updates the dockerfiles to build the binaries as part of the build process