Skip to content

[virtualization] bump to v1.11.1 - #458

Draft
universal-itengineer wants to merge 1 commit into
mainfrom
chore/virtualization/bump-cli-release-1-11
Draft

[virtualization] bump to v1.11.1#458
universal-itengineer wants to merge 1 commit into
mainfrom
chore/virtualization/bump-cli-release-1-11

Conversation

@universal-itengineer

Copy link
Copy Markdown
Member

Summary

Moves the d8 v subcommands off the pinned fix/cli/mute-warnings-during-cobra-init-release-1-6-2
revision and onto the 1.11 line of github.com/deckhouse/virtualization/src/cli.

Draft — test build, not the final pin. The src/cli/v1.11.1 tag does not exist yet
(expected 2026-08-28). Until it does, both modules point at the current release-1.11
head, 6bd3a583. Needs a repin before review.

What changed

  • src/cli: v0.0.0-20260411164351-43c8e331b69dv0.0.0-20260826084353-6bd3a583bc4e
  • api: v1.5.1v0.15.1-0.20260826084353-6bd3a583bc4e

Both modules move together and point at the same revision. Upstream src/cli/go.mod
declares api as the placeholder v0.0.0-00010101000000-000000000000 and resolves it
through the virtualization repository's go.work, which does not reach consumers — so the
consumer picks the api version, and go mod tidy cannot do it for us. Leaving api at
v1.5.1 fails the build with undefined: v1alpha2.VMOPPhaseSuperseded and
undefined: subv1alpha2.VirtualMachineSession.

The api version number goes down (v1.5.1v0.15.1-0...). Expected: the api module
has its own tag line, and the pseudo-version continues api/v0.15.0.

Also drops the stale go.mod comment telling us to move to 1.8.0 "after updating Kubernetes
to 0.34" — k8s.io/* has been on v0.34.8 since #383.

Verification

  • task build — passes
  • task lint:dev:check — 0 issues
  • ./bin/d8 v --help — subcommand list intact, now including migrate, ansible-inventory,
    collect-debug-info, port-forward
  • go test ./cmd/... ./internal/... — one failure, TestTokenConfigured/none in
    internal/strongholddiscovery. It reproduces on an unmodified main (a stronghold token
    present in the local environment), so it is not from this change.

Notes

go get for these two modules needs GOPROXY=direct. proxy.golang.org does not serve
arbitrary revisions of the nested src/cli module, and it fails the same way a wrong ref
does, which makes it easy to misdiagnose:

module github.com/deckhouse/virtualization@... found (v1.11.0),
but does not contain package github.com/deckhouse/virtualization/src/cli

The same message appears when passing the branch name instead of a SHA — go get falls back
to the root module. There is no src/cli/v1.11.x tag to use instead; the newest is
src/cli/v1.8.0.

Before merge

  • Repin both modules to the v1.11.1 tags once they exist
  • Replace the release-1.11 branch head comments in go.mod
  • Re-run build, lint and d8 v --help

Pin src/cli and api to the 1.11 line. Both modules must move together:
upstream src/cli/go.mod declares api as a placeholder resolved through the
repository's go.work, which does not reach consumers.

Until src/cli/v1.11.1 is tagged, both point at the release-1.11 head 6bd3a583.

Signed-off-by: Nikita Korolev <nikita.korolev@flant.com>
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