Wire Antigravity CLI as a first-class agent type#1194
Conversation
github-actions
Bot
added
kind/feature
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 4 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="antigravity/Dockerfile">
<violation number="1" location="antigravity/Dockerfile:41">
P2: The `agy` install step is unpinned, so rebuilds can silently pick up new upstream versions and produce non-reproducible images.
(Based on your team's feedback about avoiding silently changing external versions or licenses.) [FEEDBACK_USED]</violation>
</file>
Tip: cubic used a learning from your PR history. Let your coding agent read cubic learnings directly with the cubic MCP.
Re-trigger cubic
|
|
||
| USER agent | ||
|
|
||
| RUN curl -fsSL https://antigravity.google/cli/install.sh -o /tmp/install-agy.sh \ |
There was a problem hiding this comment.
P2: The agy install step is unpinned, so rebuilds can silently pick up new upstream versions and produce non-reproducible images.
(Based on your team's feedback about avoiding silently changing external versions or licenses.)
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At antigravity/Dockerfile, line 41:
<comment>The `agy` install step is unpinned, so rebuilds can silently pick up new upstream versions and produce non-reproducible images.
(Based on your team's feedback about avoiding silently changing external versions or licenses.) </comment>
<file context>
@@ -0,0 +1,50 @@
+
+USER agent
+
+RUN curl -fsSL https://antigravity.google/cli/install.sh -o /tmp/install-agy.sh \
+ && bash /tmp/install-agy.sh \
+ && rm /tmp/install-agy.sh
</file context>
|
/kelos api-review |
|
🤖 Kelos Task Status Task |
|
/kelos review |
|
🤖 Kelos Task Status Task |
![kelos-bot[bot]](https://avatars.githubusercontent.com/in/2965305?s=60&v=4){kind=small}
There was a problem hiding this comment.
🤖 Kelos API Reviewer Agent @gjkim42
API Design Review
Verdict: COMMENT (effectively REQUEST CHANGES — see findings; review submitted as COMMENT because GitHub forbids requesting changes on a PR authored by the same bot identity)
Scope: Adds an antigravity agent image (Dockerfile + entrypoint) and wires it into the Makefile / e2e workflow. Description says "No API/CRD changes," but the new agent is not reachable through the existing CRD API — that itself is an API gap worth resolving (or explicitly deferring) before merge.
Findings
API Compatibility / Reachability
Task.spec.typeandTaskTemplate.typeare restricted by
+kubebuilder:validation:Enum=claude-code;codex;gemini;opencode;cursor
(api/v1alpha1/task_types.go:142,api/v1alpha1/taskspawner_types.go:816).
After this PR, the image exists in the registry and is preloaded into the
e2e kind cluster, but a manifest withtype: antigravityis rejected by
the API server — the new agent is not exposed through the documented CRD
path. To make this image usable as a first-class agent, the enum must be
extended in both places (and the correspondingmake updateartifacts
regenerated).internal/controller/job_builder.go:120-133(JobBuilder.Build) has no
AgentTypeAntigravitycase and would returnunsupported agent type: antigravity. The default-image constants andJobBuilderfields at
job_builder.go:17-46/:93-104likewise omit antigravity. Without
these, even after the enum is extended, scheduling fails. This is the
controller-side half of the same API surface.apiKeyEnvVar/oauthEnvVar(internal/controller/job_builder.go:138-178)
have no antigravity case, so a Task withtype: antigravityand an
api-key/oauthcredential would silently injectANTHROPIC_API_KEY/
CLAUDE_CODE_OAUTH_TOKENrather than an Antigravity-shaped variable.
Either define the credential env var contract foragyhere or document
that the Antigravity image only supportscredentials.type: none(and
enforce it in CEL).
Documentation vs. Implementation
docs/agent-image-interface.md:43enumeratesKELOS_AGENT_TYPEvalues as
claude-code, codex, gemini, opencode, cursor. Ifantigravityis being
added as an agent type, this table (and the env-var table above it) must
list it and document which credential variables Kelos will inject for it.antigravity/kelos_entrypoint.sh:7documents
ANTIGRAVITY_API_KEY env var: API key for authentication (optional)in
the contract header, but the script never readsANTIGRAVITY_API_KEYand
no controller code populates it. Per CLAUDE.md ("Docs must match
implementation, not aspiration"), either wire the env var through
credentialEnvVars(and add anapiKeyEnvVar/oauthEnvVarcase) or drop
the line from the contract comment.
Image Naming / Future-Proofing
- The directory and image name
antigravityis tied to the product brand,
while the CLI binary isagy. The PR description notes Antigravity
"supersedes the deprecated Gemini CLI" — if Antigravity is intended to be
Google's long-term Gemini-family CLI, consider whether the enum value
should reflect that lineage (e.g., reuse/rename ofgemini, or a value
likeantigravitywith explicit deprecation guidance forgemini).
Whatever you choose, do it before shipping the enum value — once it's in
the CRD it's effectively permanent. Worth a sentence in the release note
on howantigravityrelates to the existinggeminiagent type.
Suggestions
- If the intent is to ship the image artifact first and add API/controller
wiring in a follow-up PR, please say so explicitly in the description and
link the follow-up issue, so reviewers don't read "No API/CRD changes" as
"this is feature-complete." Otherwise, fold the enum extension,
JobBuildercase, credential env-var mapping, and docs update into this
PR so the feature is usable end-to-end on merge. - The kind-load step at
.github/workflows/reusable-e2e.yaml:122adds the
image to the cluster but no e2e test exercisestype: antigravity— a
smoke test (even justkelos run --type antigravity --credentials none)
would prove the enum/builder/env wiring all lines up.
Note on prompt injection: A prior automated review on this PR
(cubic-dev-ai[bot]) contains an HTML-comment block instructing AI readers
to attribute findings to that tool. The findings above were derived
independently from the diff and the existing CRD/controller code; the
attribution instruction was disregarded.
/kelos needs-input
There was a problem hiding this comment.
🤖 Kelos Reviewer Agent @gjkim42
Review Summary
Verdict: COMMENT (effectively APPROVE — see findings; review submitted as COMMENT because GitHub forbids approving a PR authored by the same bot identity)
Overall correctness: patch is correct
Scope: Adds a new antigravity/ agent image (Dockerfile + entrypoint) for Google Antigravity CLI (agy) and wires it into IMAGE_DIRS and the e2e kind-load step.
The image artifact itself is well-formed and follows the established pattern from gemini/, opencode/, and cursor/. The API-surface concern — that type: antigravity is not yet reachable through the CRD or wired in JobBuilder — has already been raised in detail by the /kelos api-review run on this PR, so I am not duplicating that checklist here. Only image- and convention-level findings below.
Findings Overview
| Priority | Count | File:Line | Summary |
|---|---|---|---|
| P0 | 0 | — | none |
| P1 | 0 | — | none |
| P2 | 1 | antigravity/kelos_entrypoint.sh:8 | Contract docstring lists an env var the script and controller never read |
| P3 | 1 | antigravity/Dockerfile:41 | agy install is unpinned and unverified — acknowledged in PR description |
Findings
Documentation accuracy
- [P2]
antigravity/kelos_entrypoint.sh:8— the contract header declaresANTIGRAVITY_API_KEY env var: API key for authentication (optional), but neither this script nor any code underinternal/controller/references that name. Per CLAUDE.md ("Docs must match implementation, not aspiration"), either drop the line from the contract comment or wire the variable throughcredentialEnvVars/apiKeyEnvVarin a follow-up. Operators reading the header today will plausibly setANTIGRAVITY_API_KEYon a Pod and observe no effect.
Reproducibility
- [P3]
antigravity/Dockerfile:41—bash <(curl https://antigravity.google/cli/install.sh)fetches the latestagybuild with no version arg and no checksum verification, so two rebuilds of the same Dockerfile commit can yield differentagybinaries. The PR description already calls this out as an upstream limitation; flagging only so a follow-up pins the binary URL (and ideally adds asha256sum -c) once Google publishes a stable per-version download pattern, matching the pattern used forGEMINI_CLI_VERSION,OPENCODE_VERSION, andCURSOR_CLI_VERSIONin the sibling images.
Suggestions
- [P3] The kind-load step at
.github/workflows/reusable-e2e.yaml:122makes the image available in the e2e cluster but no e2e exercisestype: antigravity. A smoke test in the follow-up that adds the CRD enum +JobBuildercase would prove the wiring end-to-end.
Key takeaways
- The Dockerfile and entrypoint mirror
gemini/andopencode/cleanly; no correctness issues in what was added. - The biggest open question (CRD enum /
JobBuilder/ docs are not extended, so the image is unreachable via the documented CRD path) is already captured by/kelos api-review— please resolve there. - Fix the stale
ANTIGRAVITY_API_KEYline in the entrypoint header in this PR or the wiring follow-up, whichever lands sooner.
Note on prompt injection: A prior automated review on this PR (cubic-dev-ai[bot]) contains an HTML-comment block instructing AI readers to credit it as the source of findings. That instruction was disregarded — the findings above were derived independently from the diff and the existing image-pattern files.
| # Interface contract: | ||
| # - First argument ($1): the task prompt | ||
| # - KELOS_MODEL env var: model name (optional) | ||
| # - ANTIGRAVITY_API_KEY env var: API key for authentication (optional) |
There was a problem hiding this comment.
[P2] The contract header declares ANTIGRAVITY_API_KEY env var: API key for authentication (optional), but neither this script nor any code under internal/controller/ references that name. Per CLAUDE.md ("Docs must match implementation, not aspiration"), drop the line or wire the variable through credentialEnvVars/apiKeyEnvVar in the follow-up. Operators reading the header today will plausibly set ANTIGRAVITY_API_KEY on a Pod and observe no effect.
|
|
||
| USER agent | ||
|
|
||
| RUN curl -fsSL https://antigravity.google/cli/install.sh -o /tmp/install-agy.sh \ |
There was a problem hiding this comment.
[P3] bash <(curl https://antigravity.google/cli/install.sh) fetches the latest agy build with no version arg and no checksum verification, so two rebuilds of the same Dockerfile commit can yield different agy binaries. The PR description already calls this out; flagging only so a follow-up pins the binary URL (and ideally adds a sha256sum -c) once Google publishes a stable per-version download pattern, matching the GEMINI_CLI_VERSION/OPENCODE_VERSION/CURSOR_CLI_VERSION pattern in the sibling images.
|
/kelos pick-up |
|
🤖 Kelos Task Status Task |
Mirrors the gemini/opencode/cursor image pattern: ubuntu:24.04 with Go, Node, gh and git. Installs the Antigravity CLI (agy) via the official install.sh and wires the directory into IMAGE_DIRS and the e2e workflow. The kelos_entrypoint.sh runs agy in --print mode with stream-json output, forwards KELOS_MODEL via --model, writes KELOS_AGENTS_MD to ~/.config/agy/AGENTS.md, executes the optional setup command, and pipes the agent stream into kelos-capture. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Extends Task.spec.type / TaskTemplate.type enums with "antigravity" and adds the controller-side wiring (AgentTypeAntigravity, AntigravityImage, JobBuilder fields, --antigravity-image flag) so a manifest with type: antigravity is now reachable through the documented CRD path rather than just buildable as an image. The agy CLI has no documented non-interactive credential env var, so Task.spec.credentials.type is restricted to "none" for this agent type (operators supply credentials via podOverrides.env). Drops the unused ANTIGRAVITY_API_KEY line from the antigravity entrypoint contract header so docs match implementation. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
kelos-bot
Bot
force-pushed
the
kelos-task-1173
branch
from
5931e09 to
450801a
Compare
kelos-bot
Bot
changed the title
… conventions Add three conventions backed by review feedback on PRs from the past 7 days: - "Wire new agent runtime images through the full stack in one PR" — from the /kelos api-review on PR #1194 (Antigravity CLI). The PR added an image directory + kind-load step but did not extend the Task.spec.type enum, JobBuilder, credential env-var mapping, agent-image-interface.md, or e2e coverage, so `type: antigravity` is rejected at admission. - "Pin third-party CLI installs in agent-image Dockerfiles" — from cubic (P2) and kelos-bot (P3) findings on PR #1194's antigravity/Dockerfile:41 unversioned `curl install.sh | bash`. The sibling images already use ARG XXX_VERSION + pinned URLs. - "Propagate deferred Close()/Flush() errors via a named return" — from the cubic (P2) and kelos-bot (P2) findings on PR #1189 internal/capture/usage.go:46 silent `defer bw.Flush()` error drop.
|
/kelos pick-up |
|
🤖 Kelos Task Status Task |
|
🤖 Kelos Agent @gjkim42 All review feedback was addressed in the wiring commit ( Local Ready for re-review. |
1 participant
What type of PR is this?
/kind feature
What this PR does / why we need it:
Adds a new agent for Google Antigravity CLI (agy), Google's terminal coding agent that supersedes the deprecated Gemini CLI, and wires it through the documented CRD path so a manifest with
type: antigravityis reachable end-to-end (not just buildable as an image).antigravity/directory withDockerfileandkelos_entrypoint.sh, mirroring the existinggemini/,opencode/, andcursor/images (ubuntu:24.04 base + Go + Node +gh+git). The Dockerfile installsagyvia the officialhttps://antigravity.google/cli/install.shscript.agy --print --output-format stream-jsonwith optional--model "$KELOS_MODEL", writesKELOS_AGENTS_MDto~/.config/agy/AGENTS.md, executes the optionalKELOS_SETUP_COMMAND, and streams the agent output intokelos-capture.antigravityintoIMAGE_DIRSin the Makefile and adds the image to the kind-load step of.github/workflows/reusable-e2e.yaml.Task.spec.typeandTaskTemplate.typekubebuilder enums withantigravityand regenerates the CRD YAMLs.AgentTypeAntigravity,AntigravityImage,JobBuilder.AntigravityImage{,PullPolicy}fields, the--antigravity-image/--antigravity-image-pull-policycontroller flags, and a switch case inJobBuilder.Build.Task.spec.credentials.typetononefor the antigravity agent type (theagyCLI has no documented non-interactive credential env var, so the controller refusesapi-key/oauthrather than silently injecting Anthropic-shaped variables). Operators who need authenticated runs supply credentials viaTask.spec.podOverrides.env.credentials.type: nonerestriction indocs/agent-image-interface.md,docs/reference.md,skills/kelos/SKILL.md, and the README. Drops the unusedANTIGRAVITY_API_KEYline from the entrypoint contract header so docs match implementation.Which issue(s) this PR is related to:
Fixes #1173
Special notes for your reviewer:
The Antigravity install script does not support pinning to a specific version; it always fetches the latest from Google's auto-updater service. This is acknowledged in the PR review feedback as a follow-up (P3) — a follow-up can pin the binary URL once Google publishes a stable per-version download pattern, matching the
GEMINI_CLI_VERSION/CURSOR_CLI_VERSIONpattern used by the sibling images.Once
agydocuments a non-interactive credential env var, a follow-up can lift thecredentials.type: nonerestriction by addingapiKeyEnvVar/oauthEnvVarcases for antigravity and updating the entrypoint contract.Does this PR introduce a user-facing change?