fix: restore Go installation for v2 releases - #87
Conversation
|
No description provided. |
|
The To fix:
The core check and OS matrix are already green, so this is the only remaining blocker. |
|
Speaking as Kun's firstmate: re-checked after the later Greptile note. |
|
Speaking as Kun's firstmate: no new author push. Still blocked on |
|
Note: I addressed the root cause of the merge blocker in #105 . This will make this PR merge-able. |
|
Speaking as Kun's firstmate: still not merging. Tests on this PR are green; |
* fix(ci): checkout correct ref for fork PRs in update-vendor-hash actions/checkout defaulted to the kunchenguid/treehouse repo with a head_ref that only exists on the contributor's fork, so the fetch failed outright for every fork-originated PR (e.g. #87, fixing #62). Check out github.event.pull_request.head.repo.full_name/sha instead, which resolves for both same-repo and fork PRs. Also harden the commit step: since GITHUB_TOKEN can never push back to a fork it doesn't own, detect that case explicitly and no-op instead of failing - the preceding nix build step already verifies the corrected vendorHash builds, so there's nothing left to gate on. * fix(ci): checkout branch ref and fail loudly on stale fork vendorHash Checking out head.sha (a commit) leaves actions/checkout@v4 in detached HEAD, which breaks the final `git push` step for same-repo PRs - the one case that worked before this fix was introduced. Use head.ref (the branch name) instead, restoring a real local branch to push from. Also stop reporting success on fork PRs when vendorHash is genuinely stale: exiting 0 after only a warning let a real staleness go green with nothing fixed. Exit 1 so CI still fails loudly for that case; only an already-correct build exits 0. * no-mistakes(document): No stale docs or lint issues; workflow fix is self-contained * fix: remove .serena/ files not relevant to Treehouse .serena/.gitignore and .serena/project.yml are Serena MCP editor/tool config added incidentally by an earlier automated pass; they are not part of the vendor-hash workflow fix and were flagged by the maintainer. * no-mistakes(document): No stale docs or lint issues; change is CI-only and self-contained * fix: gitignore .serena/ and remove tracked files again .serena/.gitignore and .serena/project.yml got re-tracked by a tool step during the previous pipeline run. Adding .serena/ to .gitignore prevents it from being re-added mid-pipeline, alongside removing the two files again per maintainer feedback on PR #105.
3 participants
Testing
github.com/kunchenguid/treehouse/v2, all packages resolve under that prefix, and the existing full Go test/build matrix continues to pass on Linux, macOS, and Windows.go.modloses the/v2suffix or when any production or test Go source importsgithub.com/kunchenguid/treehouse/...without/v2.go install github.com/kunchenguid/treehouse/v2@latest, while clone URLs, GitHub release/update endpoints, Nix references, and installer repository identifiers remain unsuffixed./v2module path succeeds; the release/tag verification remains an external post-merge check because an unpublished tag cannot be exercised in repository tests.What Changed
Change the module declaration to
github.com/kunchenguid/treehouse/v2and migrate every Go self-import to that canonical prefix, including the import used byinternal/pool/pool_test.go, so all packages remain within one valid v2 module. Update only the README's Go installation command to use the/v2path; repository URLs used for cloning, releases, badges, Nix inputs, install scripts, and updater API calls continue to identify the unchanged GitHub repository and must not gain the module suffix. Add a focused root-level regression test that derives the declared module path fromgo.modand verifies it is the expected v2 path and that repository Go files contain no legacy unsuffixed self-imports, without introducing a production-only test seam.Why
Treehouse's v2 tags still declare the unsuffixed
github.com/kunchenguid/treehousemodule path, violating Go's semantic import versioning rule for major versions greater than one. Consequently, both explicit v2 installation forms fail, while the README's@latestcommand silently resolves to v1.8.0 instead of a current release. The report includes reproducible failures for v2.0.0, and a follow-up confirms the defect persists through v2.1.1. The issue is open and unassigned, with no competing or prior closed-unmerged pull requests in the supplied evidence.Fixes #62