Repository navigation
chore(ci): add area/openbao to the label set and the scope mapping - #4182
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: cozystack/cozystack/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe repository adds an ChangesOpenBAO labeling
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~2 minutes Change: Other Merge Risk: ⚪ Minimal · up to OpenBAO-scoped PRs will receive the declared Architecture SummaryArchitecture risk: 🔵 Low · up to The changed surface does not map to a changed system, dependency edge, entrypoint, or external dependency. Changed systems: None identified. Architecture concerns Review detailsBefore / after behavior
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
myasnikovdaniil LGTM. Openbao PRs get a real area now instead of the fallback, and the change still merges cleanly on current main (c983b5c).
OpenBAO is a real subsystem on main, with packages/apps/openbao, packages/system/openbao and packages/system/openbao-rd. No area/openbao label exists on the repo yet, and nothing in the current set covers secrets management, so a new area is what the rule in AGENTS.md asks for. The three issues you cite are open and about OpenBAO, which meets the bar in labels.yml. The sync workflow creates the label on merge.
I replayed the labeler's title parsing against the merged map. The titles of #4168, #4177 and #2991 all resolve to area/openbao, and a composite scope like openbao,ci gets both areas. The map has no duplicate keys, and every target it names is declared in labels.yml. When I pointed the openbao entry at an undeclared label, that check caught it. openbao-central does not exist on main yet since #4177 adds it, but a key ahead of its package costs nothing.
Non-blocking:
- This covers the
openbaopart of #4122, the scope with no existing label. The body could reference that issue. The rest stays open there:http-cachestill needs the same new-area decision, subsystem scopes likenetworkingstill fall through,kubeovnneeds normalisation, and the map has no test. - The labeler only ever adds labels, so #4168 and #4177 keep
area/uncategorizednext toarea/openbaoafter their next push. Someone has to remove it by hand. - The scope table in
docs/agents/contributing.mdhas no openbao row. It already lags the workflow for other areas, so this is optional.
Every openbao PR lands on area/uncategorized, because the labeler has no scope entry for it and there would be no label to apply if it did. #4168 and #4177 are both sitting on the fallback right now. labels.yml sets the bar for a new area at three open issues on the topic, and openbao is at three: #2787, #2483 and #2793. It also follows the shape already used for a single shipped component, next to area/kamaji, area/keycloak and area/cilium. Maps the plain `openbao` scope and `openbao-central` alongside it, since the platform instance lives in its own package and gets its own scope. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <[email protected]>
ce1321f to
3111fa7
Compare
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
myasnikovdaniil I rebased this onto current main, no conflicts. LGTM.
What this PR does
Every openbao PR lands on
area/uncategorized. The labeler has no scope entry for it, and there would be no label to apply if it did, so both #4168 and #4177 are sitting on the fallback right now.labels.ymlputs the bar for a new area at three open issues on the topic, and openbao is at three: #2787, #2483 and #2793. The shape follows what is already there for a single shipped component, next toarea/kamaji,area/keycloakandarea/cilium. The mapping takes the plainopenbaoscope andopenbao-centralalongside it, because the platform instance lives in its own package and carries its own scope.Checked that every
area/*andkind/*the labeler references is declared inlabels.yml: 27 referenced, none missing, before and after this change. zizmor and the pre-commit hooks pass, and the embedded script still parses under github-script semantics.Screenshots
No UI change.
Downstream repositories
Walked the trigger map against the diff. Nothing matches: the change is two entries under
.github/, and no trigger in the map is keyed on the label set or the labeler. No package added, renamed or removed, no platform component or variant, novalues.schema.json, noApplicationDefinition, nohack/layout change, no namespace rename.Release note
Summary by CodeRabbit
area/openbaolabel for tracking issues and pull requests related to OpenBAO.