GCP-696: Add channelGroup to ReleaseSpec model#46
Conversation
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Central YAML (base), Organization UI (inherited) Review profile: ASSERTIVE Plan: Enterprise Run ID: 📒 Files selected for processing (11)
📝 WalkthroughWalkthroughThis PR releases version 1.0.14 of the HyperFleet API specification with two main updates. First, the Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@cristianoveiga: GitHub didn't allow me to request PR reviews from the following users: ckandag, apahim. Note that only openshift-hyperfleet members and repo collaborators can review this PR, and authors cannot review their own PRs. DetailsIn response to this: Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
![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 `@CHANGELOG.md`:
- Around line 10-15: The changelog link references are stale after adding the
new release header: update the link refs at the bottom so [Unreleased] compares
from v1.0.14..HEAD (or HEAD..v1.0.14 depending on your repo convention) and add
a new [1.0.14] link that compares v1.0.13..v1.0.14; specifically edit
CHANGELOG.md to add a `[1.0.14]: .../compare/v1.0.13...v1.0.14` link and update
the existing `[Unreleased]: .../compare/v1.0.13...HEAD` to point from v1.0.14 to
HEAD (or the repo’s expected order), making sure the `[Unreleased]` and
`[1.0.14]` reference names match the headings exactly.
🪄 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: Central YAML (base), Organization UI (inherited)
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 58ec5faf-4fd8-4963-ad4e-8043e21fc446
📒 Files selected for processing (11)
CHANGELOG.mdaliases.tspmain.tspmodels-gcp/cluster/example_cluster.tspmodels-gcp/cluster/example_patch.tspmodels-gcp/cluster/example_post.tspmodels-gcp/cluster/model.tspschemas/core/openapi.yamlschemas/core/swagger.yamlschemas/gcp/openapi.yamlschemas/gcp/swagger.yaml
The version-resolution-adapter (GCP-677) reads spec.release.channelGroup to determine which Cincinnati channel to use when resolving a version to a release image (e.g. candidate-4.22, stable-4.22, fast-4.22). Without this field in the API spec, clients had no documentation or validation, and the field was not formally part of the contract. Bumps version to 1.0.14 and regenerates all four schema artifacts. Closes GCP-696 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Show channelGroup usage in create, patch, and GET response examples so clients can discover the new field from the API documentation. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Update [Unreleased] to compare from v1.0.15...HEAD and add missing [1.0.15] link per Keep a Changelog conventions. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
cristianoveiga
force-pushed
the
feat/GCP-696-add-channelgroup-to-releasespec
branch
from
d4fec7d to
72bd11c
Compare
|
@apahim: changing LGTM is restricted to collaborators DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: apahim The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
2 participants
Summary
channelGroup?: stringtoReleaseSpecinmodels-gcp/cluster/model.tsp1.0.14CHANGELOG.mdContext
The version-resolution-adapter (GCP-677) reads
spec.release.channelGroupvia CEL optional chaining to determine which Cincinnati channel group to use when resolving a version to a release image (e.g.candidate-4.22,stable-4.22,fast-4.22).Without this field formally in the API spec, clients had no documentation or validation, and
requiredFieldsGatewould fire silently. No adapter changes are needed — the CEL already handles the field.Related
Checklist
npm install./build-schema.sh gcp./build-schema.sh gcp --swagger./build-schema.sh core./build-schema.sh core --swaggerls schemas/*/openapi.yamlspectral lint schemas/core/openapi.yaml schemas/gcp/openapi.yaml🤖 Generated with Claude Code via
/jira:solve GCP-696