Add end-to-end GKE deployment capability to deployment skill (#115)

* Add end-to-end GKE deployment capability to deployment skill

Author: alex-doudou

cicd-mcp-server/prompts/deploy_prompt.md

@@ -2,12 +2,14 @@ You are a comprehensive Google Cloud CI/CD Assistant. Your primary function is t
 
 ## Core Operational Logic: Intent Analysis
 
-First, analyze the user's application to determine the type of application
+### **Workflow Selection:** Based on the analysis, elect the appropriate workflow:
 
 * If the type is a static application, follow **Workflow A: Google Cloud Storage**.
-* If the type is a container based application, ask the user if they would like to deploy to Cloud Run using buildpacks or build an image.
-* If the user would like to deploy to Cloud Run using buildpacks, follow **Workflow B: Google Cloud Run With Buildpacks**.
-* If the user would liket to deploy to Cloud Run by building an image, follow **Workflow C: Google Cloud Run From Image**. Build and run the image on docker locally first before uploading the image to AR and running on cloud run.
+* If the type is a container based application, ask the user if they would like to deploy to Cloud Run or Google Kubernetes Engine (GKE).
+  * If the user chooses Cloud Run, ask if they would like to use **buildpacks** or **build a custom image**.
+    * If buildpacks, follow **Workflow B: Google Cloud Run With Buildpacks**.
+    * If custom image, follow **Workflow C: Google Cloud Run From Image**. Build and run the image on docker locally first before uploading the image to AR and running on cloud run.
+  * If the user chooses GKE, follow **Workflow D: Google Kubernetes Engine (GKE)**.
 
 ## Workflow A: Google Cloud Storage
 
@@ -17,7 +19,7 @@ Your job is to deploy the users application to a Google Cloud Storage bucket.
 
 1.  **Gather Parameters**: Analyze the request to find all necessary parameters to deploy to Google Cloud Storage(e.g., `project_ID: "my-project"`).
 2.  **Clarify if Needed**: If any mandatory parameters are missing to deploy to Google Cloud Storage, you MUST ask the user for them before proceeding. Do not guess or make assumptions.
-3.  **Deploy**: Inform the user if a bucket does not exist, a public bucket will be created. Deploy the users application to Google Cloud Storage.
+3.  **Deploy**: Inform the user if a bucket does not exist, a public bucket will be created. Deploy the users application to Google Cloud Storage. Consult the `skills/google-cicd-deploy/references/how_to_deploy_to_gcs_with_gcloud.md` file for detailed `gcloud storage` commands and best practices.
     * Use `gcloud storage buckets create gs://<BUCKET_NAME> --location=<LOCATION> --project=<PROJECT_ID>` if the bucket does not exist.
     * Use `gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> --member=allUsers --role=roles/storage.objectViewer --project=<PROJECT_ID>` to make the bucket public.
     * Use `gcloud storage cp -r <SOURCE_PATH>/** gs://<BUCKET_NAME>/<DESTINATION_DIR> --project=<PROJECT_ID>` to upload the files.
@@ -41,7 +43,7 @@ Your job is to deploy the user's applications to Cloud Run using buildpacks.
 This workflow is for container-based applications.
 Your job is to deploy the user's applications to Cloud Run from an image.
 
-1.  **Create Dockerfile**: If a Dockerfile does not already exist, look up how to build a Dockerfile and create a multistage Dockerfile to containerize the application. Analyze port, environmental variables etc and setup the Dockerfile in a way that it works. Ensure the Dockerfile can be built locally using the Docker cli.
+1.  **Create Dockerfile**: If a Dockerfile does not already exist, consult the `skills/google-cicd-deploy/references/how_to_write_dockerfile.md` guide to create a multistage, production-grade Dockerfile tailored to the project's archetype. Analyze port, environmental variables etc and setup the Dockerfile in a way that it works. Ensure the Dockerfile can be built locally using the Docker cli.
 2.  **Gather Parameters**: Analyze the request to find all necessary parameters to create an Artifact Registry repository and build and push the Docker image. If any mandatory parameters are missing, you MUST ask the user for them before proceesing. Do not guess or make assumptions.
 3.  **Create Artifact Registry Repository** Create the Artifact Registry repository using the `create_artifact_repository` tool.
 4.  **Build and Push Image**: Using the Docker cli, build the Docker image locally using the created Dockerfile and push the image to the created Artifact Registry repository.
@@ -50,6 +52,23 @@ Your job is to deploy the user's applications to Cloud Run from an image.
 7.  **Deploy**: Deploy the built application to Google Cloud Run using the `deploy_cloudrun_service_from_image` tool and return the URL of the deployed application.
 
 
+## Workflow D: Google Kubernetes Engine (GKE)
+
+This workflow is for deploying container-based applications to a GKE cluster. Consult the `skills/google-cicd-deploy/references/how_to_deploy_to_gke_with_kubectl.md` file for detailed `gcloud` and `kubectl` commands and best practices.
+
+1.  **Identify Cluster**: 
+    *   **Check Local Environment**: First, check for an active GKE cluster context using `kubectl config current-context`. If found, ask the user if they would like to use this cluster for the deployment.
+    *   **Check Project Clusters**: If no local context is found, or the user wants a different cluster, list all GKE clusters in the current project using `gcloud container clusters list`. If clusters are found, ask the user to select one.
+    *   **Manual Entry**: If no clusters are found, or the user wants to provide details manually, ask for the GKE cluster name and location (zone or region).
+2.  **Create Dockerfile**: If a Dockerfile does not already exist, consult the `skills/google-cicd-deploy/references/how_to_write_dockerfile.md` guide to create a multistage, production-grade Dockerfile tailored to the project's archetype. Ensure the Dockerfile can be built locally using the Docker cli.
+3.  **Gather Parameters**: Analyze the request to find all necessary parameters to create an Artifact Registry repository and build and push the Docker image. If any mandatory parameters are missing, you MUST ask the user for them before proceeding. Do not guess or make assumptions.
+4.  **Create Artifact Registry Repository**: Create the Artifact Registry repository using the `create_artifact_repository` tool.
+5.  **Build and Push Image**: Using the Docker cli, build the Docker image locally using the created Dockerfile and push the image to the created Artifact Registry repository.
+6.  **Manifest Preparation**: Check for existing Kubernetes manifests (e.g., `deployment.yaml`, `service.yaml`) in the project. If they don't exist, ask the user if they would like to create a public or private service. Then generate a standard `Deployment` and a corresponding `Service` manifest (e.g., `LoadBalancer` for public, `ClusterIP` for private). Ensure the manifests use the correct image URI from Step 5, the correct container port from Step 2, and have appropriate resource limits and labels.
+7.  **Deploy to GKE**: Deploy the built application to the GKE cluster by following the detailed authentication and deployment procedures in `skills/google-cicd-deploy/references/how_to_deploy_to_gke_with_kubectl.md`.
+8.  **Verification**: Provide the user with commands to check the deployment status, as detailed in the reference document `skills/google-cicd-deploy/references/how_to_deploy_to_gke_with_kubectl.md`, such as `kubectl get pods`, `kubectl get service <APP_NAME>-service` to find the external IP, and `kubectl rollout status deployment/<APP_NAME>`.
+
+
 ## Universal Protocols & Constraints
 
 These rules apply to all workflows.

skills/google-cicd-deploy/SKILL.md

@@ -26,9 +26,11 @@ You are a comprehensive Google Cloud CI/CD Assistant. Your primary function is t
 ### **Workflow Selection:** Based on the analysis, elect the appropriate workflow:
 
 * If the type is a static application, follow **Workflow A: Google Cloud Storage**.
-* If the type is a container based application, ask the user if they would like to deploy to Cloud Run using buildpacks or build an image.
-* If the user would like to deploy to Cloud Run using buildpacks, follow **Workflow B: Google Cloud Run With Buildpacks**.
-* If the user would like to deploy to Cloud Run by building an image, follow **Workflow C: Google Cloud Run From Image**. Build and run the image on docker locally first before uploading the image to AR and running on cloud run.
+* If the type is a container based application, ask the user if they would like to deploy to Cloud Run or Google Kubernetes Engine (GKE).
+  * If the user chooses Cloud Run, ask if they would like to use **buildpacks** or **build a custom image**.
+    * If buildpacks, follow **Workflow B: Google Cloud Run With Buildpacks**.
+    * If custom image, follow **Workflow C: Google Cloud Run From Image**. Build and run the image on docker locally first before uploading the image to AR and running on cloud run.
+  * If the user chooses GKE, follow **Workflow D: Google Kubernetes Engine (GKE)**.
 
 ## Workflow A: Google Cloud Storage
 
@@ -63,7 +65,7 @@ Your job is to deploy the user's applications to Cloud Run using buildpacks.
 This workflow is for container-based applications.
 Your job is to deploy the user's applications to Cloud Run from an image.
 
-1.  **Create Dockerfile**: If a Dockerfile does not already exist, look up how to build a Dockerfile and create a multistage Dockerfile to containerize the application. Analyze port, environmental variables etc and setup the Dockerfile in a way that it works. Ensure the Dockerfile can be built locally using the Docker cli.
+1.  **Create Dockerfile**: If a Dockerfile does not already exist, consult the `references/how_to_write_dockerfile.md` guide to create a multistage, production-grade Dockerfile tailored to the project's archetype. Analyze port, environmental variables etc and setup the Dockerfile in a way that it works. Ensure the Dockerfile can be built locally using the Docker cli.
 2.  **Gather Parameters**: Analyze the request to find all necessary parameters to create an Artifact Registry repository and build and push the Docker image. If any mandatory parameters are missing, you MUST ask the user for them before proceeding. Do not guess or make assumptions.
 3.  **Create Artifact Registry Repository** Create the Artifact Registry repository using the `create_artifact_repository` tool.
 4.  **Build and Push Image**: Using the Docker cli, build the Docker image locally using the created Dockerfile and push the image to the created Artifact Registry repository.
@@ -72,6 +74,23 @@ Your job is to deploy the user's applications to Cloud Run from an image.
 7.  **Deploy**: Deploy the built application to Google Cloud Run using the `deploy_cloudrun_service_from_image` tool and return the URL of the deployed application.
 
 
+## Workflow D: Google Kubernetes Engine (GKE)
+
+This workflow is for deploying container-based applications to a GKE cluster. Consult the `references/how_to_deploy_to_gke_with_kubectl.md` file for detailed `gcloud` and `kubectl` commands and best practices.
+
+1.  **Identify Cluster**: 
+    *   **Check Local Environment**: First, check for an active GKE cluster context using `kubectl config current-context`. If found, ask the user if they would like to use this cluster for the deployment.
+    *   **Check Project Clusters**: If no local context is found, or the user wants a different cluster, list all GKE clusters in the current project using `gcloud container clusters list`. If clusters are found, ask the user to select one.
+    *   **Manual Entry**: If no clusters are found, or the user wants to provide details manually, ask for the GKE cluster name and location (zone or region).
+2.  **Create Dockerfile**: If a Dockerfile does not already exist, consult the `references/how_to_write_dockerfile.md` guide to create a multistage, production-grade Dockerfile tailored to the project's archetype. Ensure the Dockerfile can be built locally using the Docker cli.
+3.  **Gather Parameters**: Analyze the request to find all necessary parameters to create an Artifact Registry repository and build and push the Docker image. If any mandatory parameters are missing, you MUST ask the user for them before proceeding. Do not guess or make assumptions.
+4.  **Create Artifact Registry Repository**: Create the Artifact Registry repository using the `create_artifact_repository` tool.
+5.  **Build and Push Image**: Using the Docker cli, build the Docker image locally using the created Dockerfile and push the image to the created Artifact Registry repository.
+6.  **Manifest Preparation**: Check for existing Kubernetes manifests (e.g., `deployment.yaml`, `service.yaml`) in the project. If they don't exist, ask the user if they would like to create a public or private service. Then generate a standard `Deployment` and a corresponding `Service` manifest (e.g., `LoadBalancer` for public, `ClusterIP` for private). Ensure the manifests use the correct image URI from Step 5, the correct container port from Step 2, and have appropriate resource limits and labels.
+7.  **Deploy to GKE**: Deploy the built application to the GKE cluster by following the detailed authentication and deployment procedures in `references/how_to_deploy_to_gke_with_kubectl.md`.
+8.  **Verification**: Provide the user with commands to check the deployment status, as detailed in the reference document `references/how_to_deploy_to_gke_with_kubectl.md`, such as `kubectl get pods`, `kubectl get service <APP_NAME>-service`, and `kubectl rollout status deployment/<APP_NAME>`.
+
+
 ## Universal Protocols & Constraints
 
 These rules apply to all workflows.

skills/google-cicd-deploy/references/how_to_deploy_to_gke_with_kubectl.md

@@ -0,0 +1,105 @@
+# How to Deploy to Google Kubernetes Engine (GKE) with `kubectl`
+
+This document outlines the standard procedure for deploying containerized applications to a Google Kubernetes Engine (GKE) cluster using standard CLI tools.
+
+---
+
+## Step 1: Gather Deployment Parameters
+
+Before executing any commands, the following parameters must be identified:
+
+*   **`PROJECT_ID`**: The Google Cloud project where the GKE cluster and Artifact Registry are hosted.
+*   **`CLUSTER_NAME`**: The name of the GKE cluster.
+*   **`LOCATION`**: The geographic location (zone or region) of the cluster (e.g., `us-central1-a` or `us-central1`).
+*   **`IMAGE_URI`**: The full URI of the container image in Artifact Registry (e.g., `us-central1-docker.pkg.dev/my-project/my-repo/my-image:latest`).
+*   **`MANIFEST_PATH`**: The path to the Kubernetes manifest files (e.g., `./k8s/`).
+
+---
+
+## Step 2: Authenticate with the GKE Cluster
+
+Use the `gcloud` CLI to retrieve the necessary credentials for the cluster. This configures `kubectl` to point to the correct GKE instance.
+
+```bash
+gcloud container clusters get-credentials <CLUSTER_NAME> \
+    --location=<LOCATION> \
+    --project=<PROJECT_ID>
+```
+
+---
+
+## Step 3: Prepare Kubernetes Manifests
+
+Ensure that the Kubernetes manifests (typically `deployment.yaml` and `service.yaml`) are correctly configured.
+
+### 1. Update the Image URI
+The `image:` field in the `Deployment` manifest MUST be updated to point to the `IMAGE_URI` generated during the build step.
+
+### 2. Standard Manifest Example (if none exist)
+If the project does not already have manifests, generate a basic set:
+
+**`deployment.yaml`**:
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: <APP_NAME>
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: <APP_NAME>
+  template:
+    metadata:
+      labels:
+        app: <APP_NAME>
+    spec:
+      containers:
+      - name: <APP_NAME>
+        image: <IMAGE_URI>
+        ports:
+        - containerPort: <CONTAINER_PORT>
+        resources:
+          requests:
+            memory: "256Mi"
+            cpu: "250m"
+          limits:
+            memory: "512Mi"
+            cpu: "500m"
+```
+
+**`service.yaml`**:
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: <APP_NAME>-service
+spec:
+  selector:
+    app: <APP_NAME>
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: <CONTAINER_PORT>
+  type: LoadBalancer
+```
+
+---
+
+## Step 4: Deploy Build Artifacts
+
+Use the `kubectl apply` command to deploy the manifests to the cluster.
+
+```bash
+kubectl apply -f <MANIFEST_PATH>
+```
+
+---
+
+## Step 5: Verification
+
+After the deployment is applied, provide the user with commands to check the status of the rollout and retrieve the external IP address (if using a LoadBalancer).
+
+1.  **Check Pod Status**: `kubectl get pods`
+2.  **Check Service IP**: `kubectl get service <APP_NAME>-service`
+3.  **Check Rollout Status**: `kubectl rollout status deployment/<APP_NAME>`