gitlab-helm-deploy

Generate GitLab CI/CD + Helm chart

Generate a GitLab CI/CD pipeline and a Helm chart that builds the current project with kaniko, pushes to the GitLab Container Registry, and deploys to a Kubernetes namespace via a user-provided kubeconfig. Reusable across apps: inspect the repo first, ask for the unknowns, then generate only the stages and templates that apply. If no Dockerfile exists, generate one tailored to the detected runtime.

When this fires

The user wants to set up CI/CD for a project that will deploy to a Kubernetes namespace they have access to via a kubeconfig file. They will provide that kubeconfig as a base64-encoded GitLab CI variable named KUBE_CONFIG_B64. Build is kaniko, registry is GitLab Container Registry, deploy is Helm.

If the user wants something different (Argo CD, Flux, plain kubectl apply, a cloud-native registry, Docker Hub, GitHub Actions), stop and confirm before proceeding. This skill is opinionated.

Step 1: Inspect the repo first (always)

Before writing a single file, read these. Then summarize what you found in 4-8 lines and ask the user about anything ambiguous before generating files.

1. Runtime & build
   • Dockerfile: base image, exposed port, CMD/ENTRYPOINT, HEALTHCHECK. If missing, plan to generate one in Step 4.
   • package.json / pyproject.toml / go.mod / Cargo.toml / composer.json: language, framework, scripts, runtime version (engines, python_requires, go directive).
   • Lockfile: package manager (npm, pnpm, yarn, bun, poetry, pip, uv, etc.).
2. Project shape: single app, monorepo, or backend + frontend?
   • Look for top-level dirs like backend/, server/, api/ paired with frontend/, client/, web/, ui/, dashboard/: a strong signal of a split repo that needs two separate deployables.
   • Look for workspace files (pnpm-workspace.yaml, package.json workspaces, Turborepo turbo.json, Nx nx.json, Lerna): also a monorepo signal.
   • Multiple Dockerfiles (Dockerfile.backend, Dockerfile.frontend, or one per package) mean a multi-image build.
   • Frontend signals: a build that emits static assets (vite.config.*, next.config.*, vue.config.*, angular.json, dist/, build/), a different runtime (nginx for static, Node for SSR).
   • Backend signals: API entrypoint (Express, FastAPI, Gin, Rails, Spring), DB/queue clients, server-only env vars.
   • Decision rule: if both a deployable backend and a deployable frontend exist, plan two charts (helm/backend/, helm/frontend/) and two build jobs (build_backend, build_frontend). If only one exists, single chart at helm/. Confirm with the user in Step 2 before generating.
3. Routing layer of the target cluster. Different clusters use different ingress mechanisms. You must know which before generating templates:
   • GKE Gateway API (or any Gateway API cluster): generate a templates/httproute.yaml referencing a shared parent Gateway, not an Ingress.
   • ingress-nginx: generate a standard templates/ingress.yaml with ingressClassName: nginx.
   • If unsure which the cluster uses, ask in Step 2. Don't pick by guessing. A quick check the user can run: kubectl get gateways.gateway.networking.k8s.io -A (Gateway API) vs kubectl get ingressclass (look for nginx).
4. Topology & deps
   • docker-compose.yml: which external services the app talks to (Postgres, Redis, RabbitMQ, ...) and the inter-service wiring (e.g. how the frontend reaches the backend: same-origin via ingress path, separate subdomain, or env-injected URL).
   • Entrypoint source: confirm health endpoint path, port, and which env vars are actually read. Do this for each service if there are multiple.
5. Configuration
   • .env.example: enumerate every env var. Classify each as secret (API keys, passwords, tokens, signing keys) or non-secret (hosts, ports, URLs, feature flags, model names). If backend/frontend are split, partition the env vars per service. The frontend usually only needs public URLs and feature flags; secrets belong to the backend.
6. Existing CI / chart
   • If .gitlab-ci.yml or helm/ already exists, plan to replace cleanly. Don't dual-maintain. Preserve any legacy job that produces an artifact other teams depend on.