Add gemini reviewer bot

[maiqueb]

What this PR does / why we need it:
Adds gemini code reviewer bot to ease the maintainer burden on this repo.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:
Depends-on: #147

Release note:

NONE

[maiqueb]

/hold until #147 is merged.

[maiqueb]

/gemini review
/gemini summary

[maiqueb]

/gemini review
/gemini summary

[RamLavi]

I asked claude to go back 150 PRs on ipam-ext and extract @maiqueb's reviews in order to synthesize some rules that you could consider adding to your styleguide, in order to help make the PRs attuned to your review style.
Feel free to add some/all/none:

• Prefer: domain-accurate names that describe the real object or behavior.
  Example: Use secondaryAttachmentName instead of networkName when referring to a NAD attachment key.

• Prefer: extracting duplicated setup/build logic into a small helper.
  Example: Add func dummyVMWithSecondaryNet(...) *kubevirtv1.VirtualMachine instead of repeating VM spec construction in multiple tests.

• Prefer: named constants for repeated limits and timeouts.
  Example: Define const vmReadyTimeout = 5 * time.Minute and reuse it instead of mixing 5m and 90s literals.

• Prefer: tests that validate public behavior and outcomes.
  Example: Assert webhook behavior (pod admitted/rejected and mutation result) rather than testing private helper internals.

• Prefer: cleanup in teardown blocks, not in scenario flow.
  Example: Put resource deletion in AfterEach/DeferCleanup rather than inline inside It(...).

• Prefer: positive assertions that describe expected success.
  Example: Use Expect(k8sClient.Update(ctx, obj)).To(Succeed()) instead of Expect(err).NotTo(HaveOccurred()).

• Prefer: clear Ginkgo narrative (When/Context/It) that reads like behavior documentation.
  Example:
  When("persistent IP is disabled on NAD")
It("does not create an IPAMClaim").

• Prefer: explicit input types over boolean flags in function parameters.
  Example: Use createClaim(ctx, ClaimModeDryRun) / createClaim(ctx, ClaimModeApply) instead of createClaim(ctx, true).

[RamLavi]

I think gemini-code-assist is already registered for kubevirt org

gemini-code-assist are you here with us? %shandalir-shatters%

[maiqueb]

I asked claude to go back 150 PRs on ipam-ext and extract @maiqueb's reviews in order to synthesize some rules that you could consider adding to your styleguide, in order to help make the PRs attuned to your review style. Feel free to add some/all/none:

* **Prefer:** domain-accurate names that describe the real object or behavior.
  **Example:** Use `secondaryAttachmentName` instead of `networkName` when referring to a NAD attachment key.

* **Prefer:** extracting duplicated setup/build logic into a small helper.
  **Example:** Add `func dummyVMWithSecondaryNet(...) *kubevirtv1.VirtualMachine` instead of repeating VM spec construction in multiple tests.

* **Prefer:** named constants for repeated limits and timeouts.
  **Example:** Define `const vmReadyTimeout = 5 * time.Minute` and reuse it instead of mixing `5m` and `90s` literals.

* **Prefer:** tests that validate public behavior and outcomes.
  **Example:** Assert webhook behavior (pod admitted/rejected and mutation result) rather than testing private helper internals.

* **Prefer:** cleanup in teardown blocks, not in scenario flow.
  **Example:** Put resource deletion in `AfterEach`/`DeferCleanup` rather than inline inside `It(...)`.

* **Prefer:** positive assertions that describe expected success.
  **Example:** Use `Expect(k8sClient.Update(ctx, obj)).To(Succeed())` instead of `Expect(err).NotTo(HaveOccurred())`.

* **Prefer:** clear Ginkgo narrative (`When`/`Context`/`It`) that reads like behavior documentation.
  **Example:**
  `When("persistent IP is disabled on NAD")`
  `It("does not create an IPAMClaim")`.

* **Prefer:** explicit input types over boolean flags in function parameters.
  **Example:** Use `createClaim(ctx, ClaimModeDryRun)` / `createClaim(ctx, ClaimModeApply)` instead of `createClaim(ctx, true)`.

I'll use this info on #147, which actually defined the agents file.

When I figure out how to onboard gemini into the project, we'll use those guidelines again.

Nice suggestion @RamLavi , tks.

[maiqueb]

Closing until I figure out how to onboard gemini into the kubevirt org.

[RamLavi]

@maiqueb why not gemini-code-assist? From what I see it's already configured for kubevirt org.
(not that I have an idea why it doesn't work, but maybe it's not hard to find)

[maiqueb]

@gemini-code-assist can you evaluate this PR ?

[maiqueb]

/gemini review
/gemini summary

[maiqueb]

/gemini review
/gemini summary

... let's see if this does anything after the repo's got the permissions ...

[maiqueb]

@gemini-code-assist please review :)

[gemini-code-assist]

Important

Installation incomplete: to start using Gemini Code Assist, please ask the organization owner(s) to visit the Gemini Code Assist Admin Console and sign the Terms of Services.

[gemini-code-assist]

Important

Installation incomplete: to start using Gemini Code Assist, please ask the organization owner(s) to visit the Gemini Code Assist Admin Console and sign the Terms of Services.

[dhiller]

/approve

[maiqueb]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a CLAUDE.md file to provide project-specific guidance for AI coding tools, covering build commands, architecture, and design guidelines. Feedback was provided regarding violations of the document's own 120-character line length limit and a potential naming inconsistency between the file name and the pull request metadata.

[maiqueb]

/gemini review

[gemini-code-assist]

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

[qinqon]

/lgtm
/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dhiller, qinqon

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [qinqon]

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

[maiqueb]

/hold cancel