Implement runtime version injection and footer display

[Copilot]

Implements the Web Application Versioning and Build Standard: version string injection via ldflags at build time, displayed in the UI footer.

Changes

main.go

• Add var Version = "dev" for ldflags injection
• Register version template function
• Log version at startup

Dockerfile

• Add ARG VERSION=dev
• Build with -ldflags "-X 'main.Version=${VERSION}'"

GitHub Actions

• docker-build-dev.yml: Compute dev/${BRANCH}@${SHA12} and pass as build-arg
• release-docker-ghcr.yml: Pass github.ref_name (release tag) as VERSION

templates/index.html

• Add standard UnitVectorY-Labs footer with version display

Example

# Dev build injects: dev/main@1a2b3c4d5e6f
docker build --build-arg VERSION=dev/main@1a2b3c4d5e6f .

# Release build injects: v1.2.3
docker build --build-arg VERSION=v1.2.3 .

Screenshot

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• metadata.google.internal
  • Triggering command: /tmp/server /tmp/server -slog -stringintconv l/linux_amd64/vet /tmp/go-build3575277288/b357/vet.cfg /go-build mpile ux-amd64/pkg/tool/linux_amd64/vet user.name rg/toolchain@v0.-unsafeptr=false m ux-amd64/pkg/too/tmp/go-build3575277288/b177/vet.cfg conf�� 0.1-go1.25.6.linux-amd64/src/os/-p andler.go ux-amd64/pkg/tool/linux_amd64/vet (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

Web Application Versioning and Build Standard

1. Goal

Each web application MUST expose a single runtime version string that:
• Defaults to dev when not explicitly set at build time
• For production releases, equals the release tag, for example v1.2.3
• For development builds, MAY be set to dev/{BRANCH}@{SHA12} (SHA truncated to 12 chars), for example dev/main@1a2b3c4d5e6f

That version MUST be displayed in the web UI footer on every rendered page as:

Version: {VERSION}

⸻

2. Canonical version variable

2.1 Location and name
• Each repository MUST define the following in main.go at the repo root (package main):

var Version = "dev"

•	Build systems MUST override this value using Go link-time injection (ldflags). No runtime git calls.

2.2 Meaning
• Version == "dev" means a generic dev build (unknown branch and commit), acceptable fallback.
• Any other value is considered authoritative and MUST be displayed verbatim.

⸻

3. Build interface standardization

3.1 Docker build argument

All web app Docker builds MUST accept a build argument named:
• VERSION (string)

Rules:
• Default value MUST be dev if not provided.
• VERSION MUST be injected into the Go binary as main.Version.

3.2 Go build injection

The Go build step in Docker MUST set main.Version via ldflags:
• -ldflags "-X 'main.Version=${VERSION}'"

The repo MUST NOT rely on git state at runtime (no git inside runtime image and no reading .git).

⸻

4. Dockerfile requirements

For the standard multi-stage Dockerfile pattern:

4.1 Builder stage
• MUST define ARG VERSION=dev in the builder stage.
• MUST build with ldflags injection to set main.Version.
• MUST keep CGO disabled (as you already do).

Example requirement-level change (exact syntax can vary, but behavior must match):
• Add ARG VERSION=dev
• Modify the build command to:

go build -mod=readonly -o server -ldflags "-X 'main.Version=${VERSION}'" .

4.2 Runtime stage
• No changes required beyond copying the resulting binary.
• The runtime image MUST NOT require git or source code.

⸻

5. GitHub Actions requirements for web apps

5.1 Shared conventions

All workflows that build Docker images for these web apps MUST:
• Compute a VERSION string
• Pass it to Docker build as build-arg VERSION
• Not require repo-specific naming inside the Dockerfile

5.2 Development build workflow requirements

Without changing trigger behavior, the dev workflow MUST be compatible with future branch builds by deriving version from:
• Branch: github.ref_name
• Commit: github.sha truncated to 12 characters

Rules:
• The workflow MUST compute:
• SHA12 = first 12 characters of github.sha
• BRANCH = github.ref_name
• VERSION = dev/${BRANCH}@${SHA12}
• If BRANCH is empty or unavailable, the workflow MUST fall back to VERSION=dev.
• The workflow MUST pass VERSION into docker/build-push-action via build-args.

Notes:
• Do not implement feature branch tagging or retention cleanup in these requirements.
• This only defines the version string injection interface so that adding branch builds later does not require application changes.

5.3 Release workflow requirements

For the release workflow:
• The workflow MUST set VERSION to the release tag value.
• Use github.ref_name as the canonical tag string.
• The workflow MUST pass VERSION into docker/build-push-action via build-args.

This is independent from the Docker image tags produced by docker/metadata-action. The injected binary version MUST equal the release tag (for example v1.2.3), even if the image is also tagged with v1, v1.2, or a sha tag.

⸻

6. Web UI footer requirements

6.1 Footer content

All HTML pages rendered by the server MUST include the existing footer content unchanged, plus an additional second line below it that displays:

Version: {VERSION}

Constraints:
• The added line MUST visually match the existing application style (font size, color, spacing).
• It MUST be in the footer region and appear on every page using the shared layout.

6.2 Template integration requirements

Implementations MAY differ internally, but MUST meet one of the following standard patterns:

Pattern A (preferred for consistency): global template function
• The template system MUST expose a function available to the base layout, for example version, that returns the application version string.
• Footer renders Version: {{ version }} (exact template syntax depends on engine).
• This avoids passing version through every handler.

Pattern B: layout data field
• The base layout template data model MUST include a Version field populated from main.Version.
• Footer renders Version: {{ .Version }}.
• Handlers MUST populate the field consistently for all pages.

Either pattern is acceptable, but each repo MUST use exactly one chosen pattern consistently within that repo.

6.3 Source of truth
• The footer MUST display the exact value of main.Version at runtime.
• No additional parsing or normalization is required. Display verbatim.

⸻

7. Verifi...

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 0.00%. Comparing base (b4cba13) to head (be7bd9e).
⚠️ Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
main.go	0.00%	3 Missing ⚠️

Additional details and impacted files

@@          Coverage Diff          @@
##            main    #112   +/-   ##
=====================================
  Coverage   0.00%   0.00%           
=====================================
  Files          3       3           
  Lines        118     120    +2     
=====================================
- Misses       118     120    +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.