Repository navigation
bug(sdk/go): releases produce no Go module version, pkg.go.dev shows only v0.0.0 pseudo-versions #4261
Description
User Story
Go SDK consumers resolve github.com/NVIDIA/OpenShell/sdk/go through the Go module proxy and pkg.go.dev. They need a release version they can pin to that matches the OpenShell release it was built against.
Problem Statement
pkg.go.dev only shows v0.0.0-<timestamp>-<sha> pseudo-versions for the Go SDK. Go resolves a nested module's versions from tags prefixed with its directory (sdk/go/vX.Y.Z). The release process only creates root vX.Y.Z tags, which do not apply to the sdk/go module.
Impact / Why This Matters
go get github.com/NVIDIA/OpenShell/sdk/go@v0.1.2 does not resolve, and @latest returns whatever main commit the proxy last fetched. Users cannot pin the SDK to a stable release or tell which OpenShell release a given SDK version corresponds to.
Acceptance Criteria
- Each stable OpenShell release
vX.Y.Zproduces a resolvable Go SDK versionvX.Y.Z. - pkg.go.dev lists that version for
github.com/NVIDIA/OpenShell/sdk/go.
Reproduction Steps
curl -s https://proxy.golang.org/github.com/!n!v!i!d!i!a/!open!shell/sdk/go/@v/listreturns an empty list.curl -s https://proxy.golang.org/github.com/!n!v!i!d!i!a/!open!shell/sdk/go/@latestreturns a pseudo-version, e.g.v0.0.0-20261006215330-9a6148fc988a.git ls-remote --tags https://github.com/NVIDIA/OpenShell 'sdk/go/*'returns nothing.
Environment
Go module proxy (proxy.golang.org) and pkg.go.dev as of 2026-10-06; .github/workflows/release-tag.yml on main.
Activity
rhuss commentedon Oct 15, 2026
Thanks for the report and for already opening #4262.
Confirmed. The repository has no
sdk/go/*tags, the module proxy's version list forgithub.com/NVIDIA/OpenShell/sdk/gois empty, and@latestresolves to a pseudo-version of the currentmaincommit.#4262 adds a
tag-sdk-gojob torelease-tag.ymlthat createssdk/go/v<semver>at the release commit for stable releases. Thecompute-versionsoutputs it relies on exist, and because the job depends onrelease, it inherits the qualification gate from #4198. Two optional points for the review: running the workflow forv0.1.4after merge would give users a pinnable version without waiting for the next stable release, and Go handles prerelease tags (sdk/go/v0.1.5-pre.2) correctly since@latestskips them, so tagging prereleases too would make SDK testing against release candidates easier. The guard against an existing tag at a different commit matters here because the proxy caches versions permanently.@SDAChess, since you've been working on the release automation, could you take a look at #4262?
Next step: maintainer acceptance decision and review of #4262.
SDAChess commentedon Oct 15, 2026
Approved #4262