STAC-25544: move vsphere to the publicly-published VMware SDK - #368
Merged
LouisParkin merged 2 commits intoAug 6, 2026
Conversation
vsphere pinned `vsphere-automation-sdk==1.82.0`, which VMware never published
to public PyPI -- the name is squatted there by an unrelated 0.0.1 placeholder
-- so it was mirrored into the private GitLab package registry and pulled with
a credential.
That credential could not be held safely. A `pull_request` run executes the
pull request's own copy of the workflow and of every script it calls, so a run
holding a secret can always be made to disclose it. The only sound answer was
to withhold it, which meant vsphere did not run on pull requests at all and
was verified only after merge -- a real coverage gap, accepted at the time
because the alternatives cost more.
VMware publishes the same SDK to public PyPI under renamed packages, actively
maintained: pyvmomi, vmware-vcenter, vmware-vapi-runtime and
vmware-vapi-common-client, all at 9.1.0.0. Between them they satisfy every
import the check makes -- pyVmomi/pyVim, vmware.vapi.* and com.vmware.* alike.
So the pin, the credential, the separate job and the coverage gap all go
together:
- requirements.in names the four public packages
- fetch_private_wheels.sh is deleted
- PRIVATE_INDEX_CHECKS, is_private_index() and the private/deferred selector
outputs are gone; the selector now emits `checks` and `docker_checks`
- check-tests-private-index is removed and vsphere joins the ordinary matrix,
so it runs on pull requests like every other suite
- ci-success loses the private-index arm and the deferral notice
- vsphere/tox.ini no longer documents a wheelhouse that does not exist
No job in this workflow now has a secret in scope, which is a stronger and much
simpler property to maintain than any arrangement that held one.
Verified: the four pins resolve from public PyPI alone, and the full vsphere
suite passes against them -- 58 passed. actionlint, shellcheck and Zizmor clean.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
`checksdev validate dep` cross-checks every pin in a check's requirements.in against agent_requirements.in, the manifest of what the agent embeds. That file still listed vsphere-automation-sdk, so the four replacement packages were reported missing from the embedded environment. Replace the single old entry with the four public ones. Verified locally: `checksdev validate dep` exits 0, as do config, manifest, metadata and service-checks. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
Author
|
Green on run 31111900999. The one that matters: One fix on the way: |
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.
vsphere pinned
vsphere-automation-sdk==1.82.0, which VMware never published to public PyPI — the name is squatted there by an unrelated0.0.1placeholder — so it was mirrored into the private GitLab package registry and pulled with a credential.That credential could not be held safely on a public repo. A
pull_requestrun executes the PR's own copy of the workflow and every script it calls, so a run holding a secret can always be made to disclose it. The only sound answer was to withhold it, which meant vsphere never ran on pull requests and was verified only after merge.VMware publishes the same SDK to public PyPI under renamed packages, actively maintained (all
9.1.0.0, May 2026):pyvmomi,vmware-vcenter,vmware-vapi-runtime,vmware-vapi-common-client. Between them they satisfy every import the check makes —pyVmomi/pyVim,vmware.vapi.*andcom.vmware.*.So the pin, the credential, the separate job and the coverage gap all go together.
fetch_private_wheels.sh,PRIVATE_INDEX_CHECKS, andcheck-tests-private-indexare deleted; vsphere joins the ordinary matrix and runs on PRs like everything else.No job in this workflow now has a secret in scope — a much simpler property to maintain than any arrangement that held one.
Verified: the four pins resolve from public PyPI alone, and the full vsphere suite passes against them (58 passed). actionlint, shellcheck, Zizmor clean.
Stacked on #367. Once this merges, the
GITLAB_PACKAGE_REGISTRY_*grants can come off this repo in pulumi-infra.