How It Works
The CI/CD extension is a powerful three-tier system designed to translate your intent into secure, production-ready infrastructure in all these agent environments:
-
Skills: Specialized AI skills like google-cicd-deploy and google-cicd-pipeline-design are defined in the extension. These instruct your AI agent (Gemini CLI, Claude Code, or Antigravity) on how to think—helping it analyze your code, ask the right questions, and handle errors gracefully.
-
CI/CD MCP server: Running in the background is a specialized Go-based Model Context Protocol (MCP) server. This server provides a suite of tools that gives your agent the hands it needs to actually manipulate Google Cloud: everything from scanning for secrets to provisioning Cloud Run services.
-
Local knowledge base: To ensure the most accurate answers, the system includes a pre-indexed retrieval-augmented generation (RAG) database containing verified architecture patterns, which lets the agent ground its design decisions in the source of truth.
Your chosen AI assistant orchestrates these tools and patterns into a cohesive deployment lifecycle.
The Inner Loop
When you’re building a prototype or testing a new feature, you don’t need a massive, multi-environment CI/CD pipeline. You just need a public URL to test your webhook or show a stakeholder. This is the inner loop, and it needs to be fast.
The traditional approach involves manually writing a Dockerfile, authenticating with a container registry, building the image, pushing it, and finally deploying it. The CI/CD extension turns this into a single natural language prompt: gemini “Deploy this application to Google Cloud using the google-cicd-deploy skill”. If you’re using Claude Code, you can prompt it exactly the same way via claude -p “Deploy this application…”, and in Antigravity, simply type your deployment request.
When you run this prompt, your AI agent analyzes your local workspace to figure out the best deployment approach.
Step 1: Pre-Deployment Security Scan
Leaked secrets are one of the most common and expensive security failures in software. GitGuardian’s 2025 State of Secrets Sprawl report found 23.8 million new credentials exposed on public GitHub in a single year; 70% of secrets that were leaked in 2022 are still active today. It happens fast: you hardcode a database password during local testing, forget to remove it, and push.
The extension catches this before it becomes a problem. Before any code leaves your machine, it runs a secret check across your workspace. If it finds a Stripe API key or a database credential sitting in your source, the agent halts the deployment and warns you. No secrets ship to the cloud by accident.
If you accidentally commit a database password or a Stripe API key while hacking on localhost, your assistant catches it and prevents the deployment. This is what true shift-left security looks like in practice.
Step 2: Application Analysis & Containerization
Next, your agent checks your package.json or go.mod to figure out your framework. It automatically decides whether to use Google Cloud Storage (for static sites) or Cloud Run (for dynamic services).
If you’re building a dynamic service that doesn’t have a Dockerfile, the extension leverages Google Cloud’s buildpacks to containerize it for you on the fly.
Step 3: Clarification and Deployment
Conversational agents don’t blindly guess how you want your app configured. Before making any changes to your Google Cloud environment, the assistant pauses the flow to ask prioritizing questions based on what it found during its analysis.
For our Cosmic Guestbook, I didn’t specify a region or whether the service should be public. The assistant paused and asked me about it:
“I have completed the analysis and prepared the application for a unified deployment to Cloud Run. Since the Node.js buildpack requires a single entry point, I created a root package.json with a custom build script that builds the React frontend and allows the Express backend to serve it statically.
Additionally, the secret scan completed successfully, and no sensitive credentials were found.
Before we deploy using the Cloud Run source deployment option (buildpacks), I need to clarify a few deployment parameters:
-
Region/Location: The gcloud defaults do not specify a location. Which Google Cloud region would you like to deploy to (e.g., us-central1, europe-west1)?
-
Access: Should this application be publicly accessible or private?
-
Service Name: I propose naming the service cosmic-guestbook. Does that sound good to you?”
This conversational pause ensures that even in the fast inner loop, you retain complete control over your cloud architecture. After you confirm the details, the agent pushes the code live and returns the public URL:
