proof of concept for setting version number env variable

[paigewilliams]

proof of concept on triggering a docker image build on release, using the release number as a build arg, and using the arg as an env variable to display in the admin site.

[Copilot]

Pull Request Overview

This PR implements a proof of concept for dynamically setting the application version number via environment variables, enabling the version to be displayed in the Django admin site header based on GitHub release tags.

• Modified settings to read version from APP_VERSION environment variable instead of hardcoded value
• Updated docker-compose configuration to pass APP_VERSION as both a build argument and runtime environment variable
• Added GitHub Actions workflow to automate Docker image builds with version information

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
TEKDB/docker-compose.yml	Added APP_VERSION as a build arg and environment variable to pass version information to the container
TEKDB/TEKDB/settings.py	Changed VERSION from hardcoded string to read from APP_VERSION environment variable with fallback to "unknown"
.github/workflows/build-docker-image.yaml	Added new workflow to build Docker images with version information extracted from Git ref names

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Writing APP_VERSION to a .env file won't make it available to docker-compose. The .env file created here is in the GitHub Actions runner's working directory, but docker-compose looks for .env in the build context.

Instead, you should either:

1. Export it as an environment variable: echo "APP_VERSION=${GITHUB_REF_NAME#v}" >> $GITHUB_ENV
2. Or pass it directly when running docker-compose (as shown in the commented line 22)

Additionally, when the workflow is triggered by push events (as currently configured), GITHUB_REF_NAME will be the branch name, not a version tag. This will only work correctly when triggered by release events.

Suggested change

	run: echo "APP_VERSION=${GITHUB_REF_NAME#v}" >> .env
	run: echo "APP_VERSION=${GITHUB_REF_NAME#v}" >> $GITHUB_ENV

[Copilot]

The Dockerfile needs to accept the APP_VERSION build argument and set it as an environment variable. Add these lines near the top of the Dockerfile (after the base image):

ARG APP_VERSION=unknown
ENV APP_VERSION=${APP_VERSION}

Without these lines, the build arg passed from docker-compose.yml won't be captured, and the environment variable won't be available at runtime.

[Copilot]

Missing colon after push. The on trigger syntax requires a colon. This should be:

on:
  push:

or to trigger on all pushes:

on: push

The current syntax is invalid and will cause the workflow to fail.

Suggested change

	push
	push:

[rhodges]

Need to solve for not breaking the VERSION setting in a non-Docker deployment.

[rhodges]

can we run on:

• ubuntu-latest
• ubuntu 24.04 LTS
• ubuntu 22.04 LTS

We may also have partners on Ubuntu 20.04 LTS, which is now EOL, but I don't think we'll be dockerizing them - instead we'll migrate.

[rhodges]

It looks like if this is launched any way other than with Docker (looking at this variable in build-docker-image.yml and referenced again in docker-compose.yml) then the admin header will read 'unknown'. I don't think this is appropriate. I appreciate the goal of only setting this once: it's DRY and prevents conflict from potential future mis-matches, but the canonical source for this value must be platform agnostic -- at least until all deployments adopt a Docker-based system.
For now I recommend either replacing "unknown" with something meaningful like "2.2.2+" or "2.3+" or "2.3.x" or even "2.x" until the appropriate single source that works for all deployments is solved for.

[pollardld]

This is a bit over my head and am excited to learn more about how it works.