fix(gke): resolve version aliases on UpdateCluster desired versions

[avison9]

Summary

UpdateCluster stored desiredMasterVersion and desiredNodeVersion verbatim. Both fields document the same aliases as UpdateMasterRequest.master_version (latest, -, 1.X, 1.X.Y), and gcloud relies on them: gcloud container clusters upgrade C --master and ... --node-pool P both call UpdateCluster, and when no --cluster-version is given gcloud sends the literal - (api_adapter.py, UpdateClusterCommon). Against the emulator the cluster then reported currentMasterVersion: "-". Closes #196.

This is the gap noted in #192, where UpdateMaster gained alias resolution and UpdateCluster was deliberately left for its own PR.

# BEFORE
H=http://localhost:4588/container/v1/projects/p/locations/us-central1
curl -s -X POST "$H/clusters" -H 'Content-Type: application/json' -d '{"cluster":{"name":"c"}}'
curl -s -X PUT "$H/clusters/c" -H 'Content-Type: application/json' -d '{"update":{"desiredMasterVersion":"-"}}'
curl -s "$H/clusters/c" | jq .currentMasterVersion
# "-"

# AFTER
curl -s "$H/clusters/c" | jq .currentMasterVersion
# "1.30.5-gke.1014001"

What changed

• desiredMasterVersion goes through the existing resolveMasterVersion, so it behaves exactly like UpdateMaster.
• desiredNodeVersion goes through a new one-line resolveNodeVersion: identical rules, except - picks the cluster's current master version rather than the server default, which is the one documented difference between the two fields (cluster_service.proto L3542: "picks the Kubernetes master version"). The resolved value is applied to both the cluster aggregate and each targeted pool.
• Block order in updateCluster is unchanged: the node block still resolves its targets before mutating anything, so a rejected desiredNodePoolId leaves no partial state. The proto allows one ClusterUpdate field per request, so a node - reads the stored master version, not one the same request might also be changing.
• docs/services/gke.md updated.

Independent of #195 (different lines of the same file); either can merge first.

Type of change

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

GCP Compatibility

Alias semantics from ClusterUpdate.desired_master_version (L3706-L3716) and desired_node_version (L3532-L3543) in cluster_service.proto @ aa87617d67. Request shapes in the REST test are the ones gcloud sends for container clusters upgrade with and without --master.

Tests

• GkeServiceTest.updateClusterResolvesDesiredMasterVersionAliases (new): - and latest resolve to the advertised version; explicit stays verbatim; node version does not move.
• GkeServiceTest.updateClusterResolvesDesiredNodeVersionAliasesAgainstTheMaster (new): on a cluster whose master is not the advertised version, node latest resolves to the advertised version and node - resolves to the cluster's master, on both the aggregate and the pool.
• GkeUpdateClusterRestIntegrationTest (new): the two gcloud request bodies over PUT, asserting the read-back is a real version and never -.
• All three were written first and failed with but was: <-> / but was: <latest>.

Full suite: baseline on main @ c534f6b is 1043 run / 0 failures / 0 errors / 0 skipped; with this change 1046 / 0 / 0 / 0 (the 3 new tests, nothing else changed).

Checklist

• ./mvnw test passes locally
• New or updated integration test added
• Commit messages follow Conventional Commits

🤖 Generated with Claude Code

https://claude.ai/code/session_01VTYz9WSVDx9vDqBoy4K96j

[greptile-apps]

Greptile Summary

This PR fixes GKE UpdateCluster version alias handling so stored cluster and node-pool versions remain concrete.

• Resolves master aliases through the existing master-version resolver.
• Resolves node - against the cluster’s current master version and updates targeted pools consistently.
• Adds service-level and REST integration coverage for master and node upgrades.
• Documents the alias semantics used by gcloud upgrade requests.

Confidence Score: 5/5

The PR appears safe to merge, with the alias behavior consistently applied and covered through service and REST tests.

No actionable failures remain: alias resolution uses the advertised server version, node - reads a guaranteed current master version, target validation precedes mutation, and cluster and pool readbacks stay consistent.

Important Files Changed

Filename	Overview
src/main/java/io/floci/gcp/services/gke/GkeService.java	Resolves UpdateCluster master and node aliases before updating cluster and node-pool state.
src/test/java/io/floci/gcp/services/gke/GkeServiceTest.java	Adds focused coverage for master aliases, node aliases, explicit versions, and independent control-plane and node versions.
src/test/java/io/floci/gcp/services/gke/GkeUpdateClusterRestIntegrationTest.java	Verifies the gcloud-style REST request bodies produce concrete master and node versions.
docs/services/gke.md	Documents UpdateCluster alias behavior and the node-side meaning of -.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[UpdateCluster request] --> B{Version field}
    B -->|desiredMasterVersion| C[resolveMasterVersion]
    C --> D[Update currentMasterVersion]
    B -->|desiredNodeVersion| E{Requested value is dash?}
    E -->|Yes| F[Use current master version]
    E -->|No| G[resolveMasterVersion]
    F --> H[Update cluster node version]
    G --> H
    H --> I[Update targeted node pools]

Loading

_{Reviews (1): Last reviewed commit: "fix(gke): resolve version aliases on Upd..." | Re-trigger Greptile}

[hectorvent]

Thank you, and particularly for checking the one-field-per-request rule rather than assuming it, since the whole design rests on it. I confirmed all three: desired_node_version documents "-" as "picks the Kubernetes master version" where desired_master_version says "picks the default Kubernetes version", and ClusterUpdate does say "at most one field can be provided" (cluster_service.proto). Tests run 49/0 here.

1. (follow-up, separate PR) Once fix(gke): reject master version spellings the field does not document #197 lands too, a bad node version reports the master field: I merged both branches locally and desiredNodeVersion: "banana" gives 400 Invalid master version "banana": expected .... The status is right, just the field name in the text. Would you be open to passing the field name into the helper, in whichever of the two lands second?

No blockers from my side.

[hectorvent]

All three contract claims confirmed verbatim, including the one-field-per-request rule the design rests on; tests 49/0 locally.