Report build information

Task

Expose frontend + backend build information. It would be helpful to see what release version (e.g., v4.20.0-beta.23) the running instance of either the frontend component or backend component is running.

The frontend should display the current build version for both itself and the backend somewhere on the UI.

The backend should expose an endpoint that returns the current build version and other relevant metadata.

Where does the tag/build information come from?

We can and should expose the build information in the Docker image labels. Currently, we have:

# Set Docker labels
LABEL org.opencontainers.image.title="ATT&CK Workbench REST API Service" \
    org.opencontainers.image.description="This Docker image contains the REST API service of the ATT&CK Workbench, an application for exploring, creating, annotating, and sharing extensions of the MITRE ATT&CK® knowledge base. The service handles the storage, querying, and editing of ATT&CK objects. The application is built on Node.js and Express.js, and is served by the built-in web server provided by Express.js." \
    org.opencontainers.image.source="https://github.com/mitre-attack/attack-workbench-rest-api" \
    org.opencontainers.image.documentation="https://github.com/mitre-attack/attack-workbench-rest-api/README.md" \
    org.opencontainers.image.url="https://ghcr.io/mitre-attack/attack-workbench-rest-api" \
    org.opencontainers.image.vendor="The MITRE Corporation" \
    org.opencontainers.image.licenses="Apache-2.0" \
    org.opencontainers.image.authors="MITRE ATT&CK<attack@mitre.org>" \
    org.opencontainers.image.version="${VERSION}" \
    org.opencontainers.image.created="${BUILDTIME}" \
    org.opencontainers.image.revision="${REVISION}" \
    maintainer="MITRE ATT&CK<attack@mitre.org>"

Looking at an example:

❯ docker pull ghcr.io/mitre-attack/attack-workbench-rest-api:4.20.0-beta.23
❯ docker image inspect ghcr.io/mitre-attack/attack-workbench-rest-api:4.20.0-beta.23 | grep "org.opencontainers"
                "org.opencontainers.image.authors": "MITRE ATT&CK<attack@mitre.org>",
                "org.opencontainers.image.created": "2026-08-05T15:13:49.915Z",
                "org.opencontainers.image.description": "This Docker image contains the REST API service of the ATT&CK Workbench, an application for exploring, creating, annotating, and sharing extensions of the MITRE ATT&CK® knowledge base. The service handles the storage, querying, and editing of ATT&CK objects. The application is built on Node.js and Express.js, and is served by the built-in webserver provided by Express.js.",
                "org.opencontainers.image.documentation": "https://github.com/mitre-attack/attack-workbench-rest-api/README.md",
                "org.opencontainers.image.licenses": "Apache-2.0",
                "org.opencontainers.image.revision": "c2c017c146fae040caba559333b35536bfbd1189",
                "org.opencontainers.image.source": "https://github.com/mitre-attack/attack-workbench-rest-api",
                "org.opencontainers.image.title": "ATT&CK Workbench REST API Service",
                "org.opencontainers.image.url": "https://ghcr.io/mitre-attack/attack-workbench-rest-api",
                "org.opencontainers.image.vendor": "The MITRE Corporation",
                "org.opencontainers.image.version": "4.20.0-beta.23"

However, the org.opencontainers.image.version label is not mapped to a runtime environment variable — this is what we currently have:

# Set version as environment variable for runtime access
ENV APP_VERSION=${VERSION} \
    GIT_COMMIT=${REVISION} \
    BUILD_DATE=${BUILDTIME}

For non-Docker environments, I'm not sure how we would guarantee that the build information is available. We could potentially include a build-info.json file in the build artifacts that contains the same information as the Docker labels, and have the backend read from that file at runtime. This would allow us to expose the build information via an API endpoint regardless of the deployment environment. But this would require integrating the generation/updating of the build-info.json file into the semantic-release build process, which would add complexity.