Repository navigation
Build the release in CI, publish it where Kitmaker can be reached - #39
Merged
Merged
Conversation
The v1.0.0 run failed at the first Portal request with "No address associated with hostname". Kitmaker's Portal is on NVIDIA's internal network, so a GitHub-hosted runner cannot resolve it, and no amount of credentials would have changed that. The workflow could never have published. So it no longer tries. `release` builds, attaches every distribution and the SBOM to the GitHub Release, and stops. Asking Kitmaker to publish from those asset URLs is a step a maintainer runs from inside the network, which is the same shape the sibling engine repository settled on. The approval on `pypi` stays, because attaching the distributions is what makes them public, and that is now the last gate before anything is visible. With the publish gone from CI there is no stored publishing credential and no environment secret left in this repository, and the Portal address and project ids are out of a public tree. That the removal does not retract them is worth saying plainly: they have been in the history since the publish landed, and a deletion today does not reach back. The hygiene check gains the pattern that would have caught the address when it was first written, since the service is named in SECURITY.md on purpose and only the unreachable host is the problem. Two behaviours change and are documented rather than left to be found. A full re-run after the build artifact expires now goes green while the release and `dist/` hold different bytes, because the digest comparison that used to stop it lives in the publish; the publish still refuses. And the release is created without Latest so it cannot advertise a version the index lacks, but with no earlier release to hold the position GitHub reports the newest one as latest anyway, so the first release reads as Latest from the moment it exists. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Manush Murali <manushm@nvidia.com>
The intro still described one approval covering the GitHub Release and the PyPI upload together, and described the environment reviewers as holding the upload. Both were true of the workflow this change replaced. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Manush Murali <manushm@nvidia.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Manush Murali <manushm@nvidia.com>
The concurrency note described two runs refusing each other's files as stale. That refusal was in the publish script, so two runs now both succeed and the release keeps whichever build attached first. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Manush Murali <manushm@nvidia.com>
A dispatch against a tag that was already published would have made the step summary say the opposite of the truth. It now says only what this workflow did, and points at RELEASING.md for who finishes the release rather than claiming the procedure is in the tree. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Manush Murali <manushm@nvidia.com>
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
v1.0.0run failed at the first Portal request withNo address associated with hostname. Kitmaker's Portal resolves to an address onNVIDIA's internal network, so a GitHub-hosted runner cannot reach it and no
credential would have changed that. The workflow could never have published.
So it no longer tries.
releasebuilds, attaches every distribution and theSBOM to the GitHub Release, and stops. Asking Kitmaker to publish from those
asset URLs becomes a step a maintainer runs from inside the network, which is
the shape the sibling engine repository already settled on. The approval on
pypistays, because attaching the distributions is what makes them public,and that is now the last gate before anything is visible.
With the publish gone from CI there is no stored publishing credential and no
environment secret left in this repository, and the Portal address and project
ids are out of a public tree.
What is in here
publish.yml: the Kitmaker publish, the token check, the Latest promotion,the summary print and the
checkoutare gone. Nothing inreleasereads thetree any more.
kitmaker_release.pyand its tests are deleted.RELEASING.md,GOVERNANCE.mdandSECURITY.mdeach claimed CI publishesto PyPI. All three now say the build is automated and the publish is not.
check_repo_hygiene.pygains the pattern that would have caught the Portaladdress when it was first written. The service is named in
SECURITY.mdonpurpose; only the unreachable host is the problem.
Worth reviewing carefully
Removing the file does not retract the address. It has been in public
history since 75430ed, and a deletion today does not reach back. Stated here
rather than left implied.
Two behaviours change. A full re-run after the build artifact expires now
goes green while the release and
dist/hold different bytes, because thedigest comparison that used to stop it lived in the publish; the publish still
refuses. And the release is created without Latest so it cannot advertise a
version the index lacks, but with no earlier release to hold the position
GitHub reports the newest one as latest regardless, so a first release reads as
Latest from the moment it exists. Both are documented in
RELEASING.md.Checks
Hygiene 4/4, ruff clean,
publish.ymlparses, root suite 255 passed. The newhygiene pattern was verified to fire on a probe file before being kept.
🤖 Generated with Claude Code