fix(release): build the CLI against this tree, not the last published root - #48
Merged
Merged
Conversation
… root
goreleaser builds `dir: ./cmd/forge`, which is a separate module pinning
github.com/xraph/forge v1.8.2 -- its go.mod must stay free of replace
directives for `go install ...@latest` to accept it. With no workspace it
therefore compiled the CLI against the *released* root module rather than the
tag being released, so every root API added since v1.8.2 failed as "undefined":
plugins/client_diff.go:71:19: undefined: client.DiffSpecs
plugins/client.go:401:23: undefined: client.PathFilter
plugins/client.go:438:3: unknown field ReactQuery in GeneratorConfig
Nothing had regressed. internal/client/filter.go (82cdebc, Aug 3) and
internal/client/diff.go (8bc9057, Aug 4) both postdate v1.9.2, the newest
published root tag, so no released version carries them -- pinning forward does
not help either, and was measured: against v1.9.2 the PathFilter errors clear
and client_diff.go still does not build.
go.yml's "Build CLI" job already solved this with a throwaway workspace, which
is exactly why CI stayed green while the release broke -- the two jobs built the
CLI differently. This moves the same workspace to where the release can see it,
as .goreleaser.yml's first before-hook, so it applies to the real release and
the dry run alike without touching the reusable workflow in xraph/workflows.
GOWORK is pinned to $PWD because a bare `go work init` searches upward and
refuses when the checkout sits inside another workspace.
The dry-run job's "Validate module builds" step had the identical hole and would
have reported a break the release no longer has, so it gets the same treatment,
scoped by module path: the workfile stays outside the repo and everything other
than cmd/forge and extensions/database still builds with GOWORK=off, so each
module is checked standalone.
Verified with goreleaser locally: the failure reproduces exactly before the
change, and after it all five targets build -- including the three from the
failed run (linux_amd64_v1, windows_amd64_v1, darwin_arm64_v8.0). The hooks
leave no tracked file modified and go.work stays gitignored.
Does NOT fix `go install github.com/xraph/forge/cmd/forge@latest` for users,
who have no workspace. That needs a root tag cut at or after 8bc9057 and
cmd/forge/go.mod pinned to it -- a release-ordering change, not a build one.
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
Conventional Commits ValidationPR Title: valid |
A release run failed before it built anything:
git tag extensions/ai/v1.9.3 was not made against commit d07b870
This repository tags far more than the CLI -- every extension carries
`extensions/<name>/vX.Y.Z` and the editor plugin carries `vscode-forge/vX.Y.Z`.
GoReleaser takes the newest tag in the repo as "the release", so it picked up
whichever extension was tagged last and then refused, because that tag belongs
to a different commit than the one being released.
`git.ignore_tags` restricts the search to the CLI's own `vX.Y.Z` tags. Verified:
before, tag selection resolved to `current=extensions/ai/v1.9.3`; after, to
`current=v1.9.3`, and the snapshot version stamps as `1.9.3-SNAPSHOT-...`
instead of `extensions/ai/v1.9.3-SNAPSHOT-...`.
Worth noting why this survived review: snapshot builds disable tag validation,
so `goreleaser build --snapshot` reports the wrong tag as a skipped-pipe notice
and carries on. Only a real release treats it as fatal.
Contributor
Conventional Commits ValidationPR Title: valid |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The failure
The release job died in goreleaser after 5m53s:
Why
Nothing had regressed.
builds.diris./cmd/forge, a separate module pinninggithub.com/xraph/forge v1.8.2— itsgo.modmust stay free ofreplacedirectives forgo install ...@latestto accept it. With no workspace, goreleaser compiled the CLI against the published root module rather than the tag being released, so every root API added since v1.8.2 came backundefined.go.yml's "Build CLI" job already solved this with a throwaway workspace. That is exactly why CI stayed green while the release broke — the two jobs built the CLI differently.Pinning forward doesn't help:
internal/client/filter.go(82cdebcc, Aug 3) andinternal/client/diff.go(8bc90574, Aug 4) both postdatev1.9.2, the newest published root tag. Measured — against v1.9.2 thePathFiltererrors clear andclient_diff.gostill doesn't build.The change
The real release job is a reusable workflow in
xraph/workflows, so a step can't be added to it..goreleaser.ymlis in this repo and already had abefore: hooks:block, so the workspace goes there as the first hook — the existinggo mod tidyhooks resolve modules too. That covers the real release and the dry run alike, with no cross-repo change and no new tag.GOWORKis pinned to$PWDbecause a barego work initsearches upward and refuses when the checkout sits inside another workspace.The dry-run job's
Validate module buildsstep had the identical hole (for a CLI releasemodule_pathiscmd/forge) and would have reported a break the release no longer has. Same treatment, scoped by module path: the workfile stays outside the repo, and everything other thancmd/forgeandextensions/databasestill builds withGOWORK=offso each module is checked standalone — following the rationale already documented ingo.yml.Verification
Run locally with real goreleaser:
goreleaser build --snapshotreproduces the failure exactly — same symbols, same targets.linux_amd64_v1,windows_amd64_v1,darwin_arm64_v8.0). Binary runs.go.workstays gitignored.casebranches exercised with real builds:cmd/forge,extensions/database, root, and an extension.gofmt -l internal/client internal/router internal/shared cmd *.goprints nothing.Out of scope
This does not fix
go install github.com/xraph/forge/cmd/forge@latestfor users, who have no workspace and still resolve the published root module. That needs a root tag cut at or after8bc90574, thencmd/forge/go.modpinned to it — a release-ordering change rather than a build one.🤖 Generated with Claude Code