Skip to content

version: derive dev versions from git workspace state#13278

Draft
shykes wants to merge 4 commits into
mainfrom
ci-refactor-version-string
Draft

version: derive dev versions from git workspace state#13278
shykes wants to merge 4 commits into
mainfrom
ci-refactor-version-string

Conversation

@shykes
Copy link
Copy Markdown
Contributor

@shykes shykes commented May 29, 2026

Summary

Refactor the version/ Dagger module so build-time version strings come from git workspace state instead of an ad-hoc inputs filter and .changes/.next bookkeeping.

  • derive dev versions from release tags: Stop reading .changes/.next to predict the next release. Derive the next dev-version baseline from the latest v* git tag (with patch bumped) so engine/CLI dev versions are no longer coupled to Changie release-note state. Tagged release commits still resolve to the semver tag at HEAD.
  • remove unused GitRepository constructor arg: Drop the public git *GitRepository argument from the constructor — no caller passes it; the module already derives its private GitRepository from gitParent.Directory(\".git\").AsGit().
  • add workspace git shim: Drop the inputs *Directory argument and base dirty detection on git (GitRepository.Uncommitted + digest of Uncommitted.AsPatch with metadata excluded). Introduce a small workspaceGit shim that exposes only local workspace state (HEAD, branches, uncommitted, current/latest semver tag), mirroring the shape of a future core Workspace.git API so the implementation can be swapped without changing callers. Linked git worktrees are still a limitation (contextual gitParent exposes .git as a file, not a directory); a Version-level fallback emits a digestless vX.Y.Z-<timestamp>-dev from upstream tags in that case.

Test plan

  • CI green on the three engine-dev / cli-dev / release toolchains that re-export the generated version bindings
  • Spot-check dagger version from a tagged commit, an untagged clean commit, and a dirty workspace
  • Confirm dev version string still changes when uncommitted files change, and stays stable across unrelated .changes/.next edits

shykes added 4 commits May 13, 2026 07:41
The version module used .changes/.next as the predicted next release
version. That coupled build-time dev version strings to Changie release
state, so changing release-note bookkeeping could change engine and CLI dev
version computation.

Derive the next dev-version baseline from git release tags instead. Dirty
and clean untagged builds now use the latest stable v* tag with its patch
component bumped. Tagged release commits still return the semver tag that
points at HEAD.

This keeps .changes/.next out of the version module without removing the
file from the repository. Release-process cleanup can delete it separately,
without mixing that workflow change into this versioning change.

Signed-off-by: Solomon Hykes <solomon@dagger.io>
The version module exposed an optional git *GitRepository constructor argument, but the official build paths do not pass it. Prod traces show calls to dag.Version() receiving the contextual gitParent and inputs arguments only; the module then derives its private GitRepository from gitParent.Directory(".git").AsGit() when possible.

Keeping the public git argument made the versioning model look like it was already driven by a full contextual GitRepository. In practice, that path was dead for engine-dev, cli-dev, and release callers, and it obscured the real inputs that need to be replaced by Workspace.git().

Remove the public constructor argument while preserving the private GitRepository field and the existing gitParent-derived behavior. Regenerate the version module wrapper and dependent generated clients so the removed argument no longer appears in the module API.

Signed-off-by: Solomon Hykes <solomon@dagger.io>
The version module used a contextual inputs Directory to compute dirty dev
version digests. That input set had to maintain its own large ignore filter,
separate from the real build inputs. In practice that made the digest contract
fragile: every build-input change also required remembering to update a second
filter in the version module.

Remove the inputs argument and base dirty state on git instead. When local git
metadata is available, dirty detection now uses GitRepository.Uncommitted and
dirty dev digests use the digest of Uncommitted.AsPatch with metadata excluded.
This keeps the digest tied to the actual uncommitted patch instead of a
manually-maintained source snapshot.

Add a small internal workspaceGit shim to isolate the module from the current
GitRepository plumbing. The shim deliberately represents only local workspace
git state: HEAD, branches for the legacy ImageTag path, uncommitted changes,
the current semver tag, and the latest semver tag. This mirrors the shape we
want from a future core Workspace.git API, so swapping the implementation later
should be localized to the shim.

Linked git worktrees are still a current limitation because the contextual
gitParent input exposes .git as a file, not a directory. Preserve working dev
builds for that case with an explicit Version-level fallback: when local git
cannot be loaded, compute the next patch baseline from the upstream Dagger repo
tags and emit a digestless dirty dev version like vX.Y.Z-<timestamp>-dev. Keep
that fallback outside workspaceGit so the shim does not silently pretend that a
hardcoded upstream repository is workspace state.

Regenerate the version module bindings and the generated clients in cli-dev,
engine-dev, and release so the removed inputs constructor argument is reflected
in dependent modules.

Signed-off-by: Solomon Hykes <solomon@dagger.io>
Signed-off-by: Solomon Hykes <solomon@dagger.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant