fix(ci): inject git_hash / git_version / build_date as build args (LC-214) #256
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/lc-214-ci-build-provenance"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
CI-built artifacts ship with
GIT_HASH,GIT_VERSION, andBUILD_DATEbaked as the literal stringunknown, because the three Forgejo workflows never pass them as--build-argand theDockerfile.*defaults flow through..dockerignoreexcludes.git/, sobuild.rs'sgit-fallback path cannot recover the values either.Compute the three values in nushell at the top of each
Buildstep (git rev-parse --short=12 HEAD,git describe --tags --always --dirty,date now | format date "%Y-%m-%dT%H:%M:%SZ") and pass them through todocker buildx buildas--build-arg.Patched workflows:
.forgejo/workflows/build-oci-image.yml(web image).forgejo/workflows/build-desktop-linux.yml(deb / AppImage bundle).forgejo/workflows/build-desktop-windows.yml(raw.exe)Dockerfile.desktop-windows-installeris NOT patched because it wraps a pre-built.exewith NSIS; no compiled-from-source step there to consume provenance.BUILD_DATEcaptured once per build step so all images / bundles in that step share the same wall-clock anchor. The args are not content-addressable so they do not invalidate the buildx layer cache on identical source.Test plan
git_hash,git_version,build_datein nu and threads them through three--build-argflags intodocker buildx build.mainproduces an image wheredocker run dev.a8n.run/a8n-tools-private/lets-chat:latest --versionprintslets-chat 0.1.0 (<git describe>, commit <12-char hash>, built <ISO 8601>)with NOunknownsubstring.chat.pugtsurani.netreadsv0.1.0 (<hash>)instead ofv0.1.0 (unknown)./settings"About" panel on the deployed staging shows a real commit hash and ISO 8601 build date.--version.`server/build.rs` populates the compile-time env vars `GIT_HASH`, `GIT_VERSION`, and `BUILD_DATE`, which `server/src/version.rs` re-exports as `pub const`s consumed by the admin nav badge, the settings about panel, the password reset / email verification pages, the `--version` banner, and the backup archive header. Two compounding bugs caused every CI-built artifact (web OCI image, desktop linux bundle, desktop windows binary) to bake the literal string `unknown` instead of real values: 1. The three Forgejo workflows passed only `--build-arg CARGO_BUILD_JOBS=...` to `docker buildx build`, never the provenance args. `ci-build/Dockerfile.{web,desktop-linux-bundles,desktop-windows}` declare `ARG GIT_HASH=unknown` / `ARG GIT_VERSION=unknown` / `ARG BUILD_DATE=unknown` defaults followed by `ENV` lines, so the missing args flowed through as the literal default. 2. `.dockerignore:11` excludes `.git/` from the build context, so the `build.rs` fallback path (invoke `git rev-parse` / `git describe` inside the container) cannot recover the values. `build.rs` reads `env::var("GIT_HASH")` first, finds the non-empty `"unknown"` from the Dockerfile ARG, and treats it as resolved. User-visible effect on staging: the admin nav at `chat.pugtsurani.net` reads `v0.1.0 (unknown)` instead of `v0.1.0 (a1b2c3d4e5f6)`; the same `unknown` substring appears in the settings about panel and the `--version` output. In each of the three workflows, compute `git_hash` (12-char short hash), `git_version` (`git describe --tags --always --dirty`), and `build_date` (ISO-8601 UTC) in nushell at the top of the build step and pass all three through `--build-arg`. The `checkout` step already uses `fetch-depth: 0`, so `git describe` resolves tags correctly. `BUILD_DATE` is captured once per build step so every image in that step shares the same wall-clock anchor. The provenance args are NOT content-addressable, so passing them does NOT invalidate buildx's `cache-from` / `cache-to` layer cache on identical source. Left in place: - `.dockerignore:11` excluding `.git/`. Pulling `.git/` into the build context would bloat layer keys and only paper over the missing CI wiring. - The `ARG ...=unknown` defaults in the three Dockerfiles. They remain a sane fallback for ad-hoc `docker build` from a developer machine that forgets to pass the args. - `ci-build/Dockerfile.desktop-windows-installer` is not patched: it wraps a pre-built `.exe` with NSIS and has no compiled-from-source step that consumes build provenance. #LC-214