The footer says dev instead of the running commit #236

Closed
opened 2026-09-29 11:11:26 +02:00 by clawbot · 2 comments
Collaborator

sneak, 2026-09-29 in chat, after deploying upaas on fsn1app1 (verbatim):

upaas footer just says "dev" - another issue.

The version is stamped only by make build (VERSION := $(shell git describe --tags --always --dirty 2>/dev/null || echo "dev"), passed as -X main.Version). An image built from the Dockerfile (as the Compose file and the README deploy it) has no git metadata there, so the binary falls back to dev, and the operator cannot tell which commit is running.

Definition of done:

  • An image built the way the README tells an operator to (the Compose file, or docker build on a clone) shows in the footer the commit it was built from (short hash, or git describe output), with no extra flags or steps for the operator.
  • The same value is in the startup log line and wherever else upaas reports its version.
  • dev appears only for a build with no git information at all, never for an image built from a clone.
  • A test or a recorded build shows the footer value matching git rev-parse --short HEAD of the built tree.

Model: opus-5-5

sneak, 2026-09-29 in chat, after deploying upaas on fsn1app1 (verbatim): > upaas footer just says "dev" - another issue. The version is stamped only by `make build` (`VERSION := $(shell git describe --tags --always --dirty 2>/dev/null || echo "dev")`, passed as `-X main.Version`). An image built from the `Dockerfile` (as the Compose file and the README deploy it) has no git metadata there, so the binary falls back to `dev`, and the operator cannot tell which commit is running. Definition of done: - An image built the way the README tells an operator to (the Compose file, or `docker build` on a clone) shows in the footer the commit it was built from (short hash, or `git describe` output), with no extra flags or steps for the operator. - The same value is in the startup log line and wherever else upaas reports its version. - `dev` appears only for a build with no git information at all, never for an image built from a clone. - A test or a recorded build shows the footer value matching `git rev-parse --short HEAD` of the built tree. Model: opus-5-5
clawbot self-assigned this 2026-09-29 11:11:26 +02:00
Author
Collaborator

Plan.

.dockerignore excludes .git, so make build inside the Dockerfile finds no git metadata and stamps dev. Fix it in the image build itself, so docker compose up -d --build and docker build . on a clone need no extra flags:

  • Give the build stage the git metadata it needs to compute the version, for example by keeping .git in the build context. The builder stage already installs git. Watch two traps. First, git describe --dirty inside the build sees files that .dockerignore leaves out (LICENSE, REPO_POLICIES.md, ...) as deleted and appends -dirty. Second, git refuses a repository owned by another user unless safe.directory is set, and that quietly yields dev again.
  • Keep dev only for a build with no git information at all (a tarball without .git).
  • The footer, the startup log line and /health all read the same Version, so no change is needed there. Confirm they agree.
  • Test or recorded run: build the image from a clone and confirm that the footer (or /health) shows git rev-parse --short HEAD of the built tree, or the git describe output containing it. Remove the image and container afterwards.

Plain and small. No new build-arg plumbing that the operator has to pass.

Model: opus-5-5

Plan. `.dockerignore` excludes `.git`, so `make build` inside the `Dockerfile` finds no git metadata and stamps `dev`. Fix it in the image build itself, so `docker compose up -d --build` and `docker build .` on a clone need no extra flags: - Give the build stage the git metadata it needs to compute the version, for example by keeping `.git` in the build context. The builder stage already installs `git`. Watch two traps. First, `git describe --dirty` inside the build sees files that `.dockerignore` leaves out (`LICENSE`, `REPO_POLICIES.md`, ...) as deleted and appends `-dirty`. Second, git refuses a repository owned by another user unless `safe.directory` is set, and that quietly yields `dev` again. - Keep `dev` only for a build with no git information at all (a tarball without `.git`). - The footer, the startup log line and `/health` all read the same `Version`, so no change is needed there. Confirm they agree. - Test or recorded run: build the image from a clone and confirm that the footer (or `/health`) shows `git rev-parse --short HEAD` of the built tree, or the `git describe` output containing it. Remove the image and container afterwards. Plain and small. No new build-arg plumbing that the operator has to pass. Model: opus-5-5
Author
Collaborator

Implemented in #242. One change beyond the plan: no startup log line reported the version (the logger's Identify() was never called), so main now calls it.

Model: opus-5-5

Implemented in https://git.eeqj.de/sneak/upaas/pulls/242. One change beyond the plan: no startup log line reported the version (the logger's `Identify()` was never called), so `main` now calls it. Model: opus-5-5
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/upaas#236