feat: update component mappings - Model as a Service and more#100
feat: update component mappings - Model as a Service and more#100jwm4 merged 5 commits intoambient-code:mainfrom
Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 10 minutes and 51 seconds. ⌛ 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: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughUpdated Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 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 |
…ahub-operator - models-as-a-service upstream: add active branches (stable, rhoai, v0.1.x) and real branch strategy (main → stable → rhoai auto-propagation) - models-as-a-service downstream: update active branches to rhoai-3.3 through rhoai-3.4-ea.2 (dropping stale rhoai-3.0, rhoai-3.2) - Add opendatahub-io/opendatahub-operator (upstream, subcomponent: operator) with odh-3.4.0-ea.1/ea.2 active branches - Add red-hat-data-services/opendatahub-operator (downstream, no release branches yet) Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
vmrh21
force-pushed
the
update-component-mappings
branch
from
87724c4 to
279ac9b
Compare
…erator, not MaaS-specific Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
workflows/cve-fixer/component-repository-mappings.json (1)
48-109: 🧹 Nitpick | 🔵 TrivialSchema inconsistency: Model as a Service entries differ from other repository entries.
The Model as a Service repository entries are missing
protected_branches,automation, andmanual_interventionfields that are present in other repository entries (e.g., Model Serving at lines 129-219). While CLAUDE.md has hardcoded defaults for protected branches, this inconsistency may cause issues if code expects a uniform schema when iterating over repositories.Consider either:
- Adding these fields (even if empty/default values) to maintain schema consistency, or
- Removing them from all entries and relying on defaults throughout
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@workflows/cve-fixer/component-repository-mappings.json` around lines 48 - 109, The Model as a Service repository entries ("opendatahub-io/models-as-a-service" and "red-hat-data-services/models-as-a-service") lack the schema fields present elsewhere ("protected_branches", "automation", "manual_intervention"); add those fields to these two repo objects with the same default shapes/values used in other entries (e.g., empty arrays/objects or the project's default values referenced by CLAUDE.md) so the repository schema is uniform and code that iterates over repository entries (the repository mapping consumer) won't encounter missing keys.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@workflows/cve-fixer/component-repository-mappings.json`:
- Around line 65-81: The downstream mapping for
"red-hat-data-services/models-as-a-service" is missing the build_location
property which the upstream opendatahub-io/models-as-a-service expects; add a
"build_location" field to this repository object (alongside "github_url",
"default_branch", "repo_type", etc.) and set it to the same value used by the
upstream mapping so the cve_fix_workflow (primary_target/backport_targets)
behaves consistently; update the JSON entry for
"red-hat-data-services/models-as-a-service" to include "build_location":
"<upstream-build-location-value>".
- Around line 82-97: The repository entry for
"opendatahub-io/opendatahub-operator" is missing container mappings so /cve.find
cannot map images to this repo; update the container_to_repo_mapping section to
add entries for the opendatahub-io/opendatahub-operator repo (reference the repo
key "opendatahub-io/opendatahub-operator" and its cve_fix_workflow
primary_target/backport_targets) by adding the final container image names (and
any relevant tag patterns) that correspond to this operator, and remove or
replace the "Container name TBD" note in the notes field once the mapping is
added so the CVE workflow can resolve images to the repository.
- Around line 52-63: This entry is missing the build_location field so the CVE
workflow will run govulncheck from the repo root instead of the maas-api
subdirectory; update the component JSON entry that contains "subcomponent":
"maas-api" (and its "cve_fix_workflow" / "primary_target" settings) to include
"build_location": "maas-api/" so the /cve.fix job cd's into the correct
submodule before scanning.
---
Outside diff comments:
In `@workflows/cve-fixer/component-repository-mappings.json`:
- Around line 48-109: The Model as a Service repository entries
("opendatahub-io/models-as-a-service" and
"red-hat-data-services/models-as-a-service") lack the schema fields present
elsewhere ("protected_branches", "automation", "manual_intervention"); add those
fields to these two repo objects with the same default shapes/values used in
other entries (e.g., empty arrays/objects or the project's default values
referenced by CLAUDE.md) so the repository schema is uniform and code that
iterates over repository entries (the repository mapping consumer) won't
encounter missing keys.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 6b06029c-dcd1-45f1-a6c8-5b93fc234953
📒 Files selected for processing (1)
workflows/cve-fixer/component-repository-mappings.json
| "opendatahub-io/opendatahub-operator": { | ||
| "github_url": "https://github.com/opendatahub-io/opendatahub-operator", | ||
| "default_branch": "main", | ||
| "active_release_branches": [ | ||
| "odh-3.4.0-ea.1", | ||
| "odh-3.4.0-ea.2" | ||
| ], | ||
| "branch_strategy": "Fix in main. ODH release branches follow pattern odh-X.Y.Z. Also syncs to stable and rhoai branches.", | ||
| "repo_type": "upstream", | ||
| "subcomponent": "operator", | ||
| "notes": "No Dockerfile.konflux RHOAI container label found \u2014 uses rhoai.Dockerfile variant. Container name TBD.", | ||
| "cve_fix_workflow": { | ||
| "primary_target": "main", | ||
| "backport_targets": "odh-3.4.0-ea.1, odh-3.4.0-ea.2" | ||
| } | ||
| }, |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Missing container_to_repo_mapping entries for opendatahub-operator repositories.
The notes field (line 92) acknowledges this is TBD, but be aware that /cve.find commands won't be able to map container images to these repositories until the container_to_repo_mapping section is updated with the appropriate container names.
Do you want me to open an issue to track adding the container mappings once the container names are finalized?
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@workflows/cve-fixer/component-repository-mappings.json` around lines 82 - 97,
The repository entry for "opendatahub-io/opendatahub-operator" is missing
container mappings so /cve.find cannot map images to this repo; update the
container_to_repo_mapping section to add entries for the
opendatahub-io/opendatahub-operator repo (reference the repo key
"opendatahub-io/opendatahub-operator" and its cve_fix_workflow
primary_target/backport_targets) by adding the final container image names (and
any relevant tag patterns) that correspond to this operator, and remove or
replace the "Container name TBD" note in the notes field once the mapping is
added so the CVE workflow can resolve images to the repository.
stable and rhoai are 26 commits behind main — they are release snapshots not auto-propagated. v0.1.x has diverged from main. Updated to reflect manual cherry-pick backport approach. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
Use ensure_ascii=False so → and — render as readable text instead of \u2192 and \u2014. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
go.mod is in maas-api/ subdirectory — without this govulncheck and other scanners would fail at the repo root. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
workflows/cve-fixer/component-repository-mappings.json (1)
58-63:⚠️ Potential issue | 🔴 CriticalRestore
build_locationfor themaas-apimappings.
subcomponentonly scopes the component; it does not tell/cve.fixwhere to run the scan. Thesemodels-as-a-serviceentries still need"build_location": "maas-api/", otherwise the workflow scans the repo root and can miss/fail for this component in both forks.🛠️ Proposed fix
"repo_type": "upstream", "subcomponent": "maas-api", + "build_location": "maas-api/", "cve_fix_workflow": { "primary_target": "main", "backport_targets": "stable, rhoai, v0.1.x (manual cherry-pick)" } @@ "repo_type": "downstream", "subcomponent": "maas-api", + "build_location": "maas-api/", "cve_fix_workflow": { "primary_target": "main", "backport_targets": "rhoai-3.3, rhoai-3.4, rhoai-3.4-ea.1, rhoai-3.4-ea.2" }Also applies to: 75-80
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@workflows/cve-fixer/component-repository-mappings.json` around lines 58 - 63, Add the missing "build_location" property to the maas-api mapping so the CVE scanner runs in the correct subdirectory; specifically update the mapping object containing "subcomponent": "maas-api" and "cve_fix_workflow" to include "build_location": "maas-api/" (also apply the same change to the duplicate mapping around the 75-80 region), ensuring the scanner targets the maas-api/ directory rather than the repo root.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@workflows/cve-fixer/component-repository-mappings.json`:
- Around line 52-59: This mapping block adds release branches via
"active_release_branches" but omits the CVE fixer-safe "protected_branches"
field; update the JSON object that contains "active_release_branches",
"branch_strategy", "repo_type", and "subcomponent" to include a
"protected_branches" array listing the explicit release branches (e.g.,
"stable", "v0.1.x", "rhoai-3.x") so automation treats those lines as protected;
apply the same change to the other similar mapping block mentioned (the one
around the 67-76 range).
---
Duplicate comments:
In `@workflows/cve-fixer/component-repository-mappings.json`:
- Around line 58-63: Add the missing "build_location" property to the maas-api
mapping so the CVE scanner runs in the correct subdirectory; specifically update
the mapping object containing "subcomponent": "maas-api" and "cve_fix_workflow"
to include "build_location": "maas-api/" (also apply the same change to the
duplicate mapping around the 75-80 region), ensuring the scanner targets the
maas-api/ directory rather than the repo root.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 3fa7ddd5-3351-411f-85f2-c9bd34397932
📒 Files selected for processing (1)
workflows/cve-fixer/component-repository-mappings.json
| "active_release_branches": [ | ||
| "stable", | ||
| "rhoai", | ||
| "v0.1.x" | ||
| ], | ||
| "branch_strategy": "Fix in main. stable and rhoai are release snapshots \u2014 backport manually as needed. v0.1.x is a separate release branch with independent commits.", | ||
| "repo_type": "upstream", | ||
| "subcomponent": "maas-api", |
There was a problem hiding this comment.
Add protected_branches for these explicit release branches.
The CVE fixer safety rules only know custom protected branches from protected_branches. These entries now add stable, v0.1.x, and rhoai-3.x release branches but omit that field, so automation can treat release lines as writable branches.
🛡️ Proposed fix
"github_url": "https://github.com/opendatahub-io/models-as-a-service",
"default_branch": "main",
+ "protected_branches": [
+ "main",
+ "stable",
+ "rhoai",
+ "v0.1.x"
+ ],
"active_release_branches": [
"stable",
"rhoai",
"v0.1.x"
],
@@
"github_url": "https://github.com/red-hat-data-services/models-as-a-service",
"default_branch": "main",
+ "protected_branches": [
+ "main",
+ "rhoai-3.3",
+ "rhoai-3.4",
+ "rhoai-3.4-ea.1",
+ "rhoai-3.4-ea.2"
+ ],
"active_release_branches": [
"rhoai-3.3",
"rhoai-3.4",
"rhoai-3.4-ea.1",Also applies to: 67-76
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@workflows/cve-fixer/component-repository-mappings.json` around lines 52 - 59,
This mapping block adds release branches via "active_release_branches" but omits
the CVE fixer-safe "protected_branches" field; update the JSON object that
contains "active_release_branches", "branch_strategy", "repo_type", and
"subcomponent" to include a "protected_branches" array listing the explicit
release branches (e.g., "stable", "v0.1.x", "rhoai-3.x") so automation treats
those lines as protected; apply the same change to the other similar mapping
block mentioned (the one around the 67-76 range).
2 participants
Summary
opendatahub-io/models-as-a-service: active branchesstable,rhoai,v0.1.x; branch strategymain → stable → rhoaired-hat-data-services/models-as-a-service: updated active branches torhoai-3.3,rhoai-3.4,rhoai-3.4-ea.1,rhoai-3.4-ea.2(removes stalerhoai-3.0,rhoai-3.2)opendatahub-io/opendatahub-operator(upstream, subcomponent:operator) withodh-3.4.0-ea.1/ea.2red-hat-data-services/opendatahub-operator(downstream, no release branches yet)Test plan
/cve.find "Model as a Service"— verify it returns MaaS CVE tickets/cve.find "Model as a Service" maas-api— verify it scopes to maas-api container tickets only🤖 Generated with Claude Code