feat(release): register the Java services for tagging - #560
Merged
Conversation
cloud-tasks, notary and api-keys build multi-arch images and now have publish destinations in nvcf-internal, but nothing cut a tag for them: they were absent from the release registry, so no tag, no GitHub Release, and no dispatch. The publish wiring could never fire. Version continuity is the reason this is not just three new rows. Each service has a long-established line in its own upstream project -- nvct-service at v1.62.2, notary-service at 1.12.0, api-keys-service at 1.6.0 -- none of which lives in this repo. github-release synthesizes an anchor at INITIAL_RELEASE_FLOOR_VERSION when a registered service has no tag, so registering them alone would have started each at 0.1.0 and moved versions backwards for anyone pinning the upstream line. Anchor tags at the current upstream versions were pushed first, deliberately before this change. While a service is unregistered, parse_release_tag cannot match its tags, so the tag workflow skips them and no GitHub Release is created -- the anchors land as plain tags with no release or build. With them present, latest_service_tag resolves to the real version and the next conventional commit continues the line rather than restarting it. legacy_tag_prefix is intentionally unset: it selects older tags within this repository, and these services have none. Their history lives in separate projects and is carried by the anchors instead. Co-authored-by: Balaji Ganesan <bganesan@nvidia.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
📝 WalkthroughWalkthroughThe GitHub release configuration adds ChangesRelease configuration
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@tools/ci/github-release-subprojects.json`:
- Around line 245-259: Add focused tests for the new cloud-tasks, notary, and
api-keys registrations, asserting each ID, path, service_name, and version/tag
resolution; if tests cannot be added, document the omission and rationale in the
pull request description.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 9c1b3fed-9793-4c73-87b8-d726b6c327dc
📒 Files selected for processing (1)
tools/ci/github-release-subprojects.json
balajinvda
enabled auto-merge
July 30, 2026 03:31
kristinapathak
approved these changes
Jul 30, 2026
4 tasks
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
3 participants
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.
Why
cloud-tasks, notary and api-keys build multi-arch images in CI and now have
publish destinations wired in nvcf-internal, but nothing ever cut a tag for
them. They were absent from
tools/ci/github-release-subprojects.json, so notag was created, no GitHub Release existed, nothing dispatched, and the publish
config could not fire.
The registry is normally generated by
tools/generate-subproject-cifromtools/ci/subproject-validations.yaml. Neither that generator nor its configexists in this repository -- both live in the GitLab umbrella, whose default
branch is now protected against push and merge by everyone. The generated file
is therefore edited directly here, as with other mirror-only files.
Version continuity
This is the part that needed care rather than three new rows.
Each service has an established version line in its own upstream project:
nvcf/nvct/nvct-servicenvcf/nvcf-notary/notary-servicenvcf/nvcf-api-keys/api-keys-serviceNone of those tags is in this repository.
synthesize_initial_version_anchorcreates an anchor at
INITIAL_RELEASE_FLOOR_VERSION(0.0.0) for a registeredservice with no tags, so registering these alone would have made the first
release
0.1.0and moved versions backwards for anyone pinning the upstreamline. That is a silent failure: the release succeeds and the number is simply
wrong.
Anchor tags at the current upstream versions were pushed ahead of this change:
The ordering is deliberate and load-bearing.
release-tags.ymltriggers on**/v*, so those pushes did run the tag workflow -- but while a service isunregistered
parse_release_tagcannot match its tags, and the code takes theis not a supported release tag; skippingpath. The anchors landed as plaintags with no GitHub Release and no build, which I verified against the releases
API afterwards. Registering first and anchoring second would have created a
Release for a version that was never built.
legacy_tag_prefixis intentionally unset. It selects older tags within thisrepository; these services have none, and their history is carried by the
anchors.
What changed
Three entries in
tools/ci/github-release-subprojects.json.idmatches theservice_idin the nvcf-internal release config so the dispatch resolves, andpathyields the tag prefix viadefault_tag_format.Testing
python3 tools/ci/test-github-release.pypasses (7 tests). Those tests onlyconstrain services with
dev_prerelease, which these are not, so they do notcover the new rows directly.
Verified by loading
github-releaseand resolving each new entry against thepushed anchors:
Each resolves to its real upstream version rather than falling through to the
0.0.0 floor, which is the specific regression this guards against.
Usage
After merge, the next conventional commit touching each subtree cuts
v1.62.3 / 1.12.1 / 1.6.1, creates a Release, dispatches to nvcf-internal, and
publishes to ncp-dev and kaze.
Notes
The first release for each service is also the first exercise of
subtree: "."in the nvcf-internal release backend, since these build from the root module.
Worth watching rather than assuming.
api-keys is the one to reconsider before its first tag: it has an existing
api-keys-colocatedchart and is widely referenced in nvcf-internal, so it mayalready publish an image through another route.
References
None
Related Merge Requests/Pull Requests
Paired with the nvcf-internal MR adding the publish destinations.
Dependencies
None.
Summary by CodeRabbit