.coderabbit.yaml

reviews:
  path_instructions:
  - path: hack/app-sre/saas-template.yaml
    instructions: |
      This file is generated by injecting the objects in saas-objects.yaml into the stub at
      saas-template-stub.yaml. Other than checking that that has been done cleanly, any reviews of
      this file should be redundant with those for files under config/crds and should therefore be
      skipped.
  - path: hack/app-sre/saas-objects.yaml
    instructions: |-
      This file is generated by kustomize-ing the CRDs defined under config/crds. Other than
      checking that that has been done cleanly, any reviews of this file should be redundant with
      those for the CRD YAML files themselves and should therefore be skipped.
  - path: config/crds/**.yaml
    instructions: |-
      These files are generated by codegen from kubebuilder-tagged data types defined under
      [vendor/github.com/openshift/hive/]apis/hive.
      - Both copies of a given *_types.go file under those paths should be identical. We have a CI
      check to validate this; but feel free to drop a comment if you find this is not the case.
      - When reviewing the CRD schemas, please trace back and take note of the type file from which
      the section under scrutiny was generated. Only comment if that file belongs to hive. That is,
      skip inherited definitions from vendored type files. (Note that hive's type definitions are
      copied into vendor directories for generation. These are the ones we care about. So when I say
      "skip inherited definitions from vendored type files" I mean those with `vendor/` in the path
      *unless* it's `vendor/github.com/openshift/hive/...`.)
  - path: vendor/**
    instructions: |-
      These files are dependency files vendored in our codebase. We have automated testing to ensure
      that this directory is properly kept up to date with changes made to go.mod etc. Do not review
      dependency code changes, as they are out of scope for the hive repo. For example, if we upgrade
      kubernetes versions, there will be significant changes in the vendor folder. You should skip all
      of these files entirely, as reviewing code changes in kubernetes would be wildly out of scope.
      The one exception to this is `vendor/github.com/openshift/hive/**`, which should be a direct copy
      of the `apis` folder found in the root of the repo, referenced by the CRD generation guidance above.
  - path: config/hiveadmission/*-webhook.yaml
    instructions: |-
      These are configuration files for admission webhooks for hive CRs. Files named *-webhook.yaml
      contain ValidatingWebhookConfiguration (or, hypothetically, MutatingWebhookConfiguration -- but
      we don't have any of those at this time) manifests. Please validate:
      - They have been built into pkg/operator/assets/bindata.go (today our `verify` CI job should
        also check this).
      - They are all in the `webhookAssets` list in pkg/operator/hive/hiveadmission.go -- else they
        will not be deployed!
      - Each has a corresponding implementation in pkg/validating-webhooks/hive/v1.
      - When any file in this directory is added or modified, also cross-check ALL other
        existing *-webhook.yaml files in config/hiveadmission/ to verify their operations
        are consistent with their implementations. Do not limit the audit to only the file(s)
        in the diff.
      - The `Operation`s in `.webhooks[].rules[].operations` must exactly match the
        operations handled by explicit `case` branches in the implementation's `Validate()`
        switch. A `default: Allowed: true` branch does NOT count as handling an operation.
        If an operation appears in the YAML but has no corresponding `case`, flag it; and
        vice versa.
  - path: pkg/validating-webhooks/hive/v1/*_admission_hook.go
    instructions: |-
      These are implementations for validating (or, hypothetically, mutating -- but we don't have any
      of those at this time) webhooks handled by our hiveadmission service. Mirroring the above checks
      for config/hiveadmission/*-webhook.yaml, please validate that each has a corresponding
      ValidatingWebhookConfiguration (or MutatingWebhookConfiguration) manifest under config/hiveadmission/,
      built into bindata, with matching `Operation`s, and is listed for installation in hiveadmission.go.