Show build information in web UI - #257
Conversation
Signed-off-by: WilliamK112 <164879897+WilliamK112@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR threads linker-injected build metadata (version + commit) from cmd/proxy into the internal server, exposes it via the shared UI Layout, and renders it in the footer so operators can see the deployed build from any UI page.
Changes:
- Add a
BuildInfostruct and carry it throughserver.New(...)intoServerandLayout. - Render build info in the shared footer template.
- Extend server tests to cover the build-info data path and footer rendering.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| internal/server/templates/layout/footer.html | Adds build/version text to the UI footer. |
| internal/server/server.go | Stores BuildInfo on Server and plumbs it into layout data. |
| internal/server/server_test.go | Updates test server setup and asserts build info appears in rendered UI and constructor. |
| internal/server/layout.go | Introduces BuildInfo and includes it in Layout. |
| cmd/proxy/main.go | Passes linker-injected Version/Commit into server.New(...). |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
andrew
left a comment
There was a problem hiding this comment.
The shared footer reads .Version and .Commit directly. On pages whose data structs define Version, including VersionShowData and BrowseSourceData, that page field shadows Layout.BuildInfo.Version, so the footer displays package data as the proxy build version. Please reference .BuildInfo.Version and .BuildInfo.Commit explicitly and add coverage for a page with its own Version field.
Shared footer templates were reading .Version and .Commit, which resolve to package data on VersionShowData and BrowseSourceData. Point the footer at Layout.BuildInfo and cover both pages so the proxy version stays visible. Signed-off-by: WilliamK112 <164879897+WilliamK112@users.noreply.github.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Keep the BuildInfo constructor argument while picking up access logging and other mainline changes. Signed-off-by: WilliamK112 <164879897+WilliamK112@users.noreply.github.com> Co-authored-by: Cursor <cursoragent@cursor.com>
|
@andrew Footer now reads
|
andrew
left a comment
There was a problem hiding this comment.
Thanks for the update, the footer and tests now cover the shadowing case.
Two remaining items:
internal/server/layout.go:BuildInfois embedded inLayout, soVersionandCommitare still promoted throughLayoutinto every page data struct. The footer now reads.BuildInfo.Versionexplicitly, but the promotion means any template that writes{{.Version}}or{{.Commit}}still gets page-dependent behaviour. Make it a named field (BuildInfo BuildInfo) so the fields aren't promoted at all. The template,layoutFor, and the tests already access it as.BuildInfo.…, so only the struct definition changes.internal/server/server_test.go(newTestServer): theServer{}literal now has mixed alignment acrosscfg/db/storage/logger,buildInfo, andtemplates/healthCache. Please realign.
|
Addressed both remaining items on 02e8c3c:
Validation: go test ./... and git diff --check both pass. |
Summary
Why
The CLI already reports the running version and commit, but the web UI had no access to those values. Operators therefore could not identify the deployed build from the dashboard. This keeps
main.Versionandmain.Commitas the single source of truth while making the same information available on every rendered UI page.Validation
go test ./internal/servergo test ./...go test -race ./...go vet ./...go tool golangci-lint run ./...(0 issues)-X main.Version=1.2.3 -X main.Commit=abc123; bothproxy --versionand a live/ui/response containedproxy 1.2.3 (abc123)git diff --checkCloses #256