Skip to content

Add operator controller DI consistency review rules - #21

Open
sanchezl wants to merge 2 commits into
openshift:mainfrom
sanchezl:operator-di-consistency-rules
Open

Add operator controller DI consistency review rules#21
sanchezl wants to merge 2 commits into
openshift:mainfrom
sanchezl:operator-di-consistency-rules

Conversation

@sanchezl

@sanchezl sanchezl commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Add a custom check ("Operator Controller DI Consistency", warning mode) that evaluates PRs touching operator starter.go or controller constructors against 7 consistency rules
  • Add two path instruction sets for **/pkg/operator/**/starter.go (five-phase structure) and **/pkg/**/controller*.go (constructor signature conventions)

Background

Surveyed 11 OpenShift operator repos (~80 controller constructors) and found wildly inconsistent dependency injection patterns: controllers in the same operator take SharedInformerFactory vs typed informers vs bare listers vs raw cache.SharedIndexInformer, return factory.Controller vs custom structs with non-standard Run signatures, receive FeatureGateAccess vs FeatureGate vs bools vs map[string]bool.

These rules encode a consistency standard to guide reviewers. All rules are warning mode (not blocking). They self-scope to operator-pattern files and skip non-operator repos.

The Seven Rules

  1. Informers: Typed informers, not SharedInformerFactory (exception: KubeInformersForNamespaces)
  2. Clients: Narrowest sub-interface (SecretsGetter over kubernetes.Interface, never rest.Config)
  3. Lifecycle contract: Standard Run(ctx, workers) signature
  4. Parameter order: operatorClient, KubeInformersForNamespaces, typed informers, clients, feature gates, eventRecorder (last)
  5. Feature gates: Resolved-at-construction (bool/FeatureGate) by default; resolved-at-sync (FeatureGateAccess) when no construction-time decisions depend on gates
  6. Lister extraction: Controllers extract listers internally from informers
  7. Starter structure: Five phases (Clients, Informer Factories, Feature Gates, Controllers, Start)

Test Plan

  • YAML validates successfully
  • Custom check name under 50 chars, instructions under 10,000 chars
  • Path instruction fields under 20,000 chars
  • No existing rules modified
  • CodeRabbit parses the config on push (automatic validation)

Summary by CodeRabbit

  • New Features
    • Added automated pull request checks for operator startup wiring and controller dependency-injection consistency.
    • Introduced warning-mode evaluation focused on typed informer usage, narrow client interfaces, controller Run(ctx, workers int) signature conformance, and constructor parameter ordering.
    • Added path-specific review guidance for operator starter and controller files, including feature-gate state handling expectations and internal lister extraction requirements.

Add a custom check and two path instruction sets that guide reviewers
toward consistent dependency injection patterns in OpenShift operator
controller constructors and starter.go files.

The rules encode a seven-point consistency standard derived from
surveying 11 operator repos (~80 controller constructors):

1. Typed informers over SharedInformerFactory
2. Narrowest client sub-interface
3. Standard Run(ctx, workers) lifecycle contract
4. Consistent parameter ordering
5. Resolved-at-construction feature gate handling (default)
6. Internal lister extraction
7. Five-phase starter.go structure

All rules are warning-mode. They fire only on files matching operator
patterns (pkg/operator/**/starter.go, pkg/**/controller*.go) and
self-scope via instructions to skip non-operator repos.
@openshift-ci
openshift-ci Bot requested review from everettraven and jerpeter1 July 24, 2026 15:12
@openshift-ci

openshift-ci Bot commented Jul 24, 2026

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: sanchezl
Once this PR has been reviewed and has the lgtm label, please assign dgoodwin for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@coderabbitai

coderabbitai Bot commented Jul 24, 2026

Copy link
Copy Markdown

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 728121c6-9d21-4fcc-8937-6e9c5a9c9ba9

📥 Commits

Reviewing files that changed from the base of the PR and between e8b29f7 and daa69fe.

📒 Files selected for processing (1)
  • .coderabbit.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
  • .coderabbit.yaml

Walkthrough

Adds a warning-mode review check and path-scoped instructions enforcing dependency injection and startup structure conventions for operator starters and controllers.

Changes

Operator DI consistency

Layer / File(s) Summary
Operator DI review rules and scoped instructions
.coderabbit.yaml
Adds the Operator Controller DI Consistency warning check and path instructions covering startup phases, typed informers, narrow clients, feature gates, listers, constructor ordering, and run signatures.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested reviewers: everettraven, jerpeter1

🚥 Pre-merge checks | ✅ 16
✅ Passed checks (16 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly matches the main change: adding operator controller DI consistency review rules.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names ✅ Passed Only .coderabbit.yaml changed; no Ginkgo test titles were added or modified, so this check is not applicable.
Test Structure And Quality ✅ Passed No Ginkgo test code changed; PR only updates .coderabbit.yaml for operator DI rules, so this test-quality check is not applicable.
Microshift Test Compatibility ✅ Passed Only .coderabbit.yaml changed; no new Ginkgo e2e tests or MicroShift-sensitive code were added, so this check is not applicable.
Single Node Openshift (Sno) Test Compatibility ✅ Passed No Go or Ginkgo e2e test files were added; the PR only updates config/docs, so the SNO compatibility check is not applicable.
Topology-Aware Scheduling Compatibility ✅ Passed Only .coderabbit.yaml changed; no deployment, operator, or controller code was modified, so the topology-scheduling check is not applicable.
Ote Binary Stdout Contract ✅ Passed Only .coderabbit.yaml changed; no OTE binaries or process-level stdout code was modified, so the stdout contract check is not applicable.
Ipv6 And Disconnected Network Test Compatibility ✅ Passed Only .coderabbit.yaml changed; no Ginkgo/e2e test code was added, so the IPv4/external-connectivity check is not triggered.
Operator Controller Di Consistency ✅ Passed PASS: .coderabbit.yaml adds the warning-mode check with all 7 rules and both path instruction globs matching the PR summary.
No-Weak-Crypto ✅ Passed PR only edits .coderabbit.yaml operator DI instructions; no added MD5/SHA1/DES/RC4/3DES/Blowfish/ECB, custom crypto, or secret-comparison code.
Container-Privileges ✅ Passed The PR only changes .coderabbit.yaml; no container/K8s manifests or privilege settings are in the diff.
No-Sensitive-Data-In-Logs ✅ Passed PR only edits .coderabbit.yaml review rules; no application logging code or sensitive values were added, so the no-sensitive-data-in-logs check is not triggered.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 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 @.coderabbit.yaml:
- Around line 521-525: Update the starter informer rule in the configuration to
explicitly allow v1helpers.KubeInformersForNamespaces, matching the exception
already permitted by the global and controller-specific rules. Apply the same
wording consistently to the corresponding duplicated rules identified in the
diff, while continuing to reject other informer factories, raw informers, and
bare listers.
- Around line 511-518: Update both path-scoped instruction blocks for “Operator
Controller DI Consistency” to require that the repository is an OpenShift
operator repository before applying the check. Preserve the existing
startup-wiring and controller-constructor path conditions, and ensure the same
repository guard is added to the additional matching block.
🪄 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: 98816303-6207-48aa-bb69-dbce36882403

📥 Commits

Reviewing files that changed from the base of the PR and between 5fd1012 and e8b29f7.

📒 Files selected for processing (1)
  • .coderabbit.yaml

Comment thread .coderabbit.yaml
Comment on lines +511 to +518
- name: "Operator Controller DI Consistency"
mode: warning
instructions: |
This check applies only when a PR touches operator startup wiring
(starter.go, RunOperator) or controller constructors (New*Controller
functions) in OpenShift operator repositories. Skip this check if
the PR does not modify these files.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Apply the non-operator repository guard to both path instructions.

The custom check is explicitly scoped to OpenShift operator repositories, but neither path-scoped block repeats that condition. Matching paths in an unrelated repository can therefore trigger these operator rules, violating the stated PR scope.

Proposed fix
     - path: "**/pkg/operator/**/starter.go"
       instructions: |
+        Apply only in OpenShift operator repositories. If this is not an
+        OpenShift operator repository, ignore the remainder of these instructions.
         Operator starter file. Review for the five-phase structure:
...
     - path: "**/pkg/**/controller*.go"
       instructions: |
+        Apply only in OpenShift operator repositories. If this is not an
+        OpenShift operator repository, ignore the remainder of these instructions.
         If this file contains a controller constructor (New*Controller

Also applies to: 586-588, 620-623

🤖 Prompt for 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.

In @.coderabbit.yaml around lines 511 - 518, Update both path-scoped instruction
blocks for “Operator Controller DI Consistency” to require that the repository
is an OpenShift operator repository before applying the check. Preserve the
existing startup-wiring and controller-constructor path conditions, and ensure
the same repository guard is added to the additional matching block.

Comment thread .coderabbit.yaml
The custom check rule already allowed KubeInformersForNamespaces as
an exception to the "no factory objects" rule, but the starter.go and
controller path instructions did not mention it. Add the exception
to both path instruction sets for consistency.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant