Inject git commit hash and message as Docker build args
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 37.4k
- Forks
- 3k
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 73
Description
Summary
During Docker image builds, automatically inject the last git commit hash and message as build args (DOKPLOY_COMMIT_HASH and DOKPLOY_COMMIT_MESSAGE), so users can expose them as runtime environment variables in their Dockerfiles.
Motivation
Currently there's no way to access git commit information at runtime inside deployed containers. This is useful for:
- Displaying version/commit info in application UIs or health endpoints
- Debugging which exact commit is running in a given deployment
- Logging and observability
Proposed Solution
After cloning the repo and before running docker build, extract the commit info via git commands and pass them as --build-arg:
DOKPLOY_COMMIT_HASH=$(git rev-parse --short HEAD 2>/dev/null || echo "unknown")
DOKPLOY_COMMIT_MESSAGE=$(git log -1 --pretty=%s 2>/dev/null || echo "unknown")
docker build ... --build-arg DOKPLOY_COMMIT_HASH="$DOKPLOY_COMMIT_HASH" --build-arg DOKPLOY_COMMIT_MESSAGE="$DOKPLOY_COMMIT_MESSAGE"
Users would then add to their Dockerfile:
ARG DOKPLOY_COMMIT_HASH
ARG DOKPLOY_COMMIT_MESSAGE
ENV DOKPLOY_COMMIT_HASH=$DOKPLOY_COMMIT_HASH
ENV DOKPLOY_COMMIT_MESSAGE=$DOKPLOY_COMMIT_MESSAGE
This should be applied to all relevant builders (dockerfile, railpack, etc.).
I'm going to work on this and submit a PR.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue identifies Docker builds and the dockerfile and railpack builders as the relevant entry points; start by locating those builders and how they currently invoke docker build. Confirm the commit hash and message are available as build args for every relevant builder, with the documented Dockerfile ARG/ENV usage working as the done condition.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, git
- Domain
- build-system, devops
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100