feat(gcp): add Cloud SQL and GKE adapters

[TheSaifZaman]

Narrowed: messaging moved to #157 and secrets to #156, so this is now just the two GCP services that share the operation-envelope handling. Independent of both — off main.

Service	Was	Now
GCP Cloud SQL	coming_soon	list, create, inspect, delete
GCP GKE	coming_soon	list, create, inspect, delete

Both were coming_soon because the frontend said so — the runtime has been serving them all along. With availability now registry-derived (#153), each is a catalog row plus an adapter and no frontend change.

The thing most worth reviewing

/v1/projects/{p}/locations/{l}/clusters on floci-gcp is not GKE. It is Managed Service for Apache Kafka. It answers 200, returns objects called clusters, and creating one succeeds — so a "GKE adapter" bound there would have looked entirely healthy while listing Redpanda brokers as Kubernetes clusters.

The payload and the container gave it away:

$ curl -s .../v1/projects/floci-local/locations/us-central1/clusters/probe | jq
{ "bootstrapAddress": "172.20.0.5:9092", "vcpuCount": 3, "memoryBytes": 3221225472 }
$ docker ps
floci-kafka-probe   redpandadata/redpanda:latest

GKE lives at /container/v1/... and behaves like Kubernetes:

$ curl -s .../container/v1/projects/floci-local/locations/us-central1/clusters | jq '.clusters[0]'
{ "name": "probe-k8s", "status": "RUNNING", "endpoint": "localhost:6550",
  "currentMasterVersion": "1.30.5-gke.1014001",
  "nodePools": [{"name": "default-pool", "status": "RUNNING"}], "masterAuth": {...} }
$ docker ps
floci-gke-probe-k8s   rancher/k3s:latest

Worth flagging because the capability guard from #153 could not have caught it — the schema and the adapter would have agreed with each other perfectly. There is now a test asserting the adapter calls /container/v1/, with the reason in a comment.

Three operation envelopes

Google's mutations return a receipt, and the shape differs per service. All three are present on this runtime:

Service	Shape	Embeds the resource?
Cloud Functions / Run	{done, response}	yes
Cloud SQL	sql#operation + targetId	no
GKE	{status, operationType, targetLink}	no

The first cut of Cloud SQL echoed the receipt and surfaced the operation UUID as the resource name. adapter-gcp/operations.ts keeps that discrimination in one place; the two that only name the resource are read back.

Cloud SQL is also PostgreSQL-only on this runtime — it rejects every other engine — so the schema offers Postgres versions rather than the full GCP list.

Verification

pnpm lint, type-check, test, build pass. Against the live stack, both round-trip create → list → inspect → delete with no container left behind:

Cloud SQL: create → postgres:15.18-alpine container, RUNNABLE, ip 172.20.0.5, connectionName floci-local:us-central1:...
GKE:       create → rancher/k3s container, RUNNING, endpoint localhost:6550, default-pool

create spawns real containers, so exercising it locally needs #154 (Docker socket). List, inspect and delete work without it, and nothing here depends on that PR to compile or test.

README service matrix regenerated.

Type of change

• Bug fix (fix:)
• New feature / service UI (feat:)
• Breaking change (feat!: or fix!:)
• Docs / chore

Area

• Frontend (packages/frontend)
• API / Cloud Proxy (packages/api)
• Cloud Explorer adapter / schema
• Build / CI / Docker

Checklist

• pnpm lint, pnpm type-check, pnpm test, and pnpm build pass locally
• New or updated tests added where it makes sense (bun test in packages/api)
• No fake/mock data added
• Commit messages / PR title follow Conventional Commits

[greptile-apps]

Greptile Summary

Registers live GCP Cloud SQL and GKE adapters in the Cloud Explorer registry and expands their schemas for list/create/inspect/delete.

• Adds GcpCloudSqlAdapter against sqladmin v1beta4 with operation-receipt re-read and Postgres-only create fields.
• Adds GcpGkeAdapter on /container/v1/.../clusters (not the Kafka clusters path) with operation targetLink resolution.
• Centralizes GCP operation envelope handling in adapter-gcp/operations.ts and wires both adapters in cloudProxy.ts; regenerates the README service matrix.

Confidence Score: 5/5

This PR appears safe to merge; the prior FIFO create issue is no longer present on the reviewed HEAD, and no remaining blocking failures were identified.

No blocking failure remains. The earlier SQS FifoQueue create gap is addressed by commit cfaf653 (sets Attributes.FifoQueue for .fifo names), and that adapter path is not part of the current HEAD tree under review.

Important Files Changed

Filename	Overview
packages/api/src/adapter-gcp/GcpCloudSqlAdapter.ts	Cloud SQL adapter lists/creates/gets/deletes instances and re-reads after sql#operation receipts.
packages/api/src/adapter-gcp/GcpGkeAdapter.ts	GKE adapter uses /container/v1 paths and resolves create via targetLink re-read.
packages/api/src/adapter-gcp/operations.ts	Shared helpers distinguish embedded resources from SQL/GKE operation receipts.
packages/api/src/cloudProxy.ts	Registers GcpCloudSqlAdapter and GcpGkeAdapter in the cloud adapter registry.
packages/api/src/cloud-spi/databaseSchema.ts	Cloud SQL schema gains create fields, actions, columns, and capability rows.
packages/api/src/cloud-spi/eksSchema.ts	GKE schema gains create fields, actions, columns, and capability rows.

Sequence Diagram

sequenceDiagram
  participant UI as Cloud Explorer UI
  participant API as CloudProxy / registry
  participant SQL as GcpCloudSqlAdapter
  participant GKE as GcpGkeAdapter
  participant GCP as floci-gcp :4588
  UI->>API: "create/list/get/delete database|k8s"
  API->>SQL: database ops
  SQL->>GCP: /sql/v1beta4/.../instances
  GCP-->>SQL: "sql#operation or instance"
  SQL->>GCP: GET instance (when receipt only)
  API->>GKE: k8s ops
  GKE->>GCP: /container/v1/.../clusters
  GCP-->>GKE: Operation targetLink or cluster
  GKE->>GCP: GET cluster (when receipt only)

Loading

_{Reviews (4): Last reviewed commit: "docs: regenerate the service matrix" | Re-trigger Greptile}

[TheSaifZaman]

Good catch on the FIFO create — that was a real bug and it's fixed.

The adapter accepted a .fifo name and reported the resulting queue as fifo-queue, but never sent Attributes.FifoQueue=true, which real SQS requires.

Worth noting why it survived both layers of verification, since it's a trap for the other service PRs too:

• The unit test used a stub that accepts any input, so create({queueName: 'orders.fifo'}) resolved happily.
• Floci core infers FIFO from the .fifo suffix, so creating one against the live runtime also succeeded — it even came back typed fifo-queue, which is what made it look verified end to end.

So both the mock and the emulator were more forgiving than AWS, and the gap would only have shown up against the real service. Fixed by sending the attribute, with tests asserting it is set for a .fifo name and omitted otherwise:

$ curl -s -X POST .../aws/services/messaging/resources -d '{"queueName":"floci-fifo-check.fifo"}'
  create: 201
  type: fifo-queue | arn: arn:aws:sqs:us-east-1:000000000000:floci-fifo-check.fifo

CI is green.

[hectorvent]

Thanks for this one, and especially for catching that /v1/projects/{p}/locations/{l}/clusters on the runtime is Managed Kafka, not GKE. That is exactly the kind of trap that would have shipped looking healthy, and pinning the /container/v1/ prefix with a test plus a comment explaining why is the right way to keep it caught. operations.ts centralizing the three operation-envelope shapes is also a nice touch that the other GCP adapters can now lean on.

The split from the original bundle (messaging to #157, secrets to #156) reads well, and keeping Cloud SQL and GKE together here makes sense given they share the envelope handling.

One small behavioral question, not a blocker:

• In GcpGkeAdapter.create, Number(input.values.initialNodeCount ?? 1) maps an empty string to 0, which passes the Number.isFinite check, so a blank text field could send initialNodeCount: 0 instead of the documented default of 1. Could you treat blank (and non-positive) input as the default? Something like parsing via stringValue first, or guarding with > 0, would cover it, and a one-line test alongside the existing "defaults the node count" case would lock it in.

Nit, take or leave: the schemas advertise every action as available with runtimeRequired: true for create, and the PR body notes create needs the Docker socket work in #154 to actually spawn containers locally. If the runtime without #154 answers create with an error, the adapter surfaces it, so this is fine as is; just flagging in case you would rather mark create with a reason until #154 lands.

Everything else checks out: registration follows the current catalog pattern (adapters plus cloudProxy.ts, no frontend edits needed), the capability claims are backed by real adapter methods, tests assert concrete request paths and bodies rather than mocking everything away, and the README matrix was regenerated. Nice work.

[hectorvent]

🎉 This PR is included in version 0.3.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀