The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

scripts/common-envs.mk (2)

5-7: Expose new knobs clearly (docs/help)
With autodetection removed, users must set BUILDER/PLATFORM explicitly. Please add a short README blurb or a make “help” target showing examples:

• BUILDER=mybuilder
• PLATFORM=linux/amd64,linux/arm64
• BUILDX_EXTRA_ARGS=--progress=plain

---

6-6: Strip trailing whitespace
Minor style nit; “PLATFORM ?=” currently has a trailing space which is easy to propagate in diffs.

-PLATFORM ?= 
+PLATFORM ?=

packages/apps/mysql/Makefile (1)

15-15: Consistent adoption of $(BUILDX_ARGS) — check digest JSON compatibility

Looks good. Ensure the metadata JSON still contains "containerimage.digest" under your current buildx/provenance settings; otherwise yq extraction will break.

If you foresee per-target extras (e.g., build-arg overrides), confirm BUILDX_ARGS appends BUILDX_EXTRA_ARGS so targets can opt-in without touching Makefiles.

packages/core/testing/Makefile (1)

23-23: e2e-sandbox developer UX — default to --load for local runs

For this dev-heavy target, ensure BUILDX_ARGS chooses --load by default when REGISTRY or PUSH isn’t set, so docker run later can pull from the local daemon without requiring a registry push.

Document in scripts/common-envs.mk how to flip between load/push (e.g., PUSH=1 make image-e2e-sandbox).

packages/extra/monitoring/Makefile (1)

17-17: Centralized flags: parity check and minor Make hygiene

Change looks fine; same parity checks as other targets apply.

Consider marking phony targets to avoid timestamp pitfalls:

• .PHONY: image generate

Optional, low impact.

packages/system/kamaji/Makefile (1)

20-20: Add a fail-fast guard for missing containerimage.digest
Ensure images/kamaji.json contains .containerimage.digest after the build to avoid writing an invalid tag. For example, right before updating values.yaml add:

DIGEST="$(yq -r '."containerimage.digest" // empty' images/kamaji.json)"
[ -n "$DIGEST" ] || { echo "Missing containerimage.digest (did you --push?)"; exit 1; }

packages/apps/http-cache/Makefile (1)

14-14: Same here: keep command robust if BUILDX_ARGS is empty and validate digest availability

• Prevent a stray backslash if BUILDX_ARGS is empty by moving it before the last flag.

-        --metadata-file images/nginx-cache.json \
-        $(BUILDX_ARGS)
+        $(BUILDX_ARGS) \
+        --metadata-file images/nginx-cache.json

• The subsequent echo relies on containerimage.digest. Verify BUILDX_ARGS ensures a push/registry export; otherwise images/nginx-cache.json may lack the digest.

packages/system/cozystack-api/Makefile (1)

15-15: Consolidation looks good; add two sanity checks

• Move BUILDX_ARGS before the final flag to avoid a trailing backslash hazard if it’s empty.

-        --metadata-file images/cozystack-api.json \
-        $(BUILDX_ARGS)
+        $(BUILDX_ARGS) \
+        --metadata-file images/cozystack-api.json

• Ensure scripts/common-envs.mk composes BUILDX_ARGS with:
  • a source label (org.opencontainers.image.source) and desired provenance policy,
  • mutually compatible options (e.g., disallow --load with multi-arch --platform lists),
  • a push/registry export so images/cozystack-api.json has containerimage.digest used in values.yaml.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: nbykov0
PR: cozystack/cozystack#932
File: packages/system/dashboard/images/kubeapps-apis/Dockerfile:15-17
Timestamp: 2025-05-14T16:58:01.478Z
Learning: When working with Dockerfiles for cross-architecture builds in the kubeapps-apis component, the `TARGETOS` and `TARGETARCH` build arguments should be declared without default values so that Docker's buildx system can automatically set these variables based on the specified target platform.

Learnt from: nbykov0
PR: cozystack/cozystack#932
File: packages/core/testing/images/e2e-sandbox/Dockerfile:7-8
Timestamp: 2025-05-14T16:57:29.651Z
Learning: In Dockerfiles supporting cross-architecture builds, `TARGETOS` and `TARGETARCH` are special build arguments that should be declared without default values. Docker's buildx system automatically sets these variables based on the specified target platform during cross-platform builds.

Learnt from: nbykov0
PR: cozystack/cozystack#932
File: packages/apps/kubernetes/images/cluster-autoscaler/Dockerfile:3-4
Timestamp: 2025-05-14T16:54:50.368Z
Learning: In Dockerfiles for the cozystack project, ARG ordering where a variable like ${TARGETARCH} is referenced before being declared can still work correctly in practice because Docker's BuildKit may evaluate the variable only when it's actually used in a FROM statement.

Learnt from: nbykov0
PR: cozystack/cozystack#932
File: packages/system/dashboard/images/kubeapps-apis/Dockerfile:15-17
Timestamp: 2025-05-14T16:58:01.478Z
Learning: When working with Dockerfiles for cross-architecture builds in the kubeapps-apis component, the `TARGETOS` and `TARGETARCH` build arguments should be declared without default values so that Docker's buildx system can automatically set these variables based on the specified target platform.

Learnt from: nbykov0
PR: cozystack/cozystack#932
File: packages/core/testing/images/e2e-sandbox/Dockerfile:7-8
Timestamp: 2025-05-14T16:57:29.651Z
Learning: In Dockerfiles supporting cross-architecture builds, `TARGETOS` and `TARGETARCH` are special build arguments that should be declared without default values. Docker's buildx system automatically sets these variables based on the specified target platform during cross-platform builds.

Learnt from: nbykov0
PR: cozystack/cozystack#932
File: packages/apps/kubernetes/images/cluster-autoscaler/Dockerfile:3-4
Timestamp: 2025-05-14T16:54:50.368Z
Learning: In Dockerfiles for the cozystack project, ARG ordering where a variable like ${TARGETARCH} is referenced before being declared can still work correctly in practice because Docker's BuildKit may evaluate the variable only when it's actually used in a FROM statement.