Migrate CLI to v1 public API; retire v1beta1 and v1alpha1 (except IDE)#2093
Migrate CLI to v1 public API; retire v1beta1 and v1alpha1 (except IDE)#2093jeremybeard wants to merge 6 commits into
Conversation
Retires the astro-client-core (v1alpha1), astro-client-iam-core (iam/v1beta1), and astro-client-platform-core (platform/v1beta1) generated clients in favor of a single unified astro-client-v1 built from the public versioned/v1.0 spec released in astronomer/astro#37986. - New: astro-client-v1/ — unified client with Organization, Workspace, Cluster, Deployment, Deploy, User, Team, ApiToken, Environment, Authorization, and other tags. - Renamed: astro-client-core/ → astro-client-v1alpha1/, shrunk to IDE-only (Polaris Project, Polaris Session). - Deleted: astro-client-iam-core/, astro-client-platform-core/, cloud/platformclient/. - Two endpoints stay on v1alpha1 because the server has no v1 equivalent: private/v1alpha1/cli/auth-config and /v1alpha1/telemetry. Structural adaptations required by v1: - ApiToken: scope is carried on the token itself; per-scope CRUD endpoints collapse to CreateApiToken / UpdateApiToken / UpdateApiTokenRoles / RotateApiToken / DeleteApiToken. Token creation is now a two-step CreateApiToken + UpdateApiTokenRoles flow. - Users/teams: role mutations go through UpdateUserRoles / UpdateTeamRoles with full-role-set replacement. - Deployment create/update: most optional fields are pointer-typed; wrappers absorb the shape changes. Client-side defaults for optional fields (scheduler size, hybrid scheduler AU/replicas, default worker queue, task-pod node pool) are removed — the server applies defaults. - Deployment: WorkloadIdentity → EffectiveWorkloadIdentity. - Deploys: UpdateDeploy(BundleTarballVersion) → FinalizeDeploy. - Deploy git metadata: v1 CreateDeployGitRequest wired in with GITHUB and GENERIC provider branches (remoteUrl for non-GitHub SSH remotes). Other cleanups in scope: - Use Go 1.26 new() builtin for pointer init; drop the ptrOf helper. - Drop 'core client' vocabulary from the live tree; rename type alias CoreClient → APIClient; use astroV1Client throughout. - Upgrade oapi-codegen to v2.6.0 and replace the shell patch with a function-scope-aware Go program at scripts/patch-v1-gen/ that rewrites the remaining oneOf discriminator setter bug. Production fixes surfaced during migration: - cloud/deployment/inspect/inspect.go: format DeploymentEnvironmentVariable.UpdatedAt as RFC3339 before mapstructure decode (v1 changed the field from string to time.Time; inspect was broken for any deployment with env vars). - cmd/cloud/deployment.go: uppercase --cloud-provider input before validating against the ClusterCloudProvider enum so lowercase input keeps working.
c468b4a to
76c63cd
Compare
akshayarora
left a comment
There was a problem hiding this comment.
Thanks for the migration work. Left one comment.
| } else { | ||
| developmentModeValue = false | ||
| } | ||
| var workerConcurrency int |
There was a problem hiding this comment.
im assuming this deletion is intentional?
There was a problem hiding this comment.
Yes, very recently the create deployment API was changed to make the worker queues optional, so dropping this logic. There's more we could do later here to have the server apply even more defaults.
| WorkloadIdentity: deplWorkloadIdentity, | ||
| RemoteExecution: remoteExecution, | ||
| } | ||
| if !remoteExecutionEnabled { |
There was a problem hiding this comment.
im assuming this deletion is intentional?
| WorkloadIdentity: deplWorkloadIdentity, | ||
| RemoteExecution: remoteExecution, | ||
| } | ||
| if !remoteExecutionEnabled { |
There was a problem hiding this comment.
im assuming this deletion is intentional?
|
I wonder how difficult it would be to wire up some component type integration tests that use the cli such that refactors like this do not require the full suite of manual tests you had to run. |
| if workloadIdentity == "" { | ||
| if currentDeployment.WorkloadIdentity != nil { | ||
| workloadIdentity = *currentDeployment.WorkloadIdentity | ||
| if currentDeployment.EffectiveWorkloadIdentity != nil { |
There was a problem hiding this comment.
heads up, the swap from WorkloadIdentity to EffectiveWorkloadIdentity is forced (v1's Deployment only exposes the effective one, per the field doc: "either user-configured or Astronomer-provided default"), but it does shift behavior in this fallback path
previously, if the deployment had no user-configured identity, currentDeployment.WorkloadIdentity was nil and we skipped the assignment, so the Update sent no identity and the server kept managing it. now, EffectiveWorkloadIdentity is non-nil whenever a default is in effect, so an Update without --workload-identity on a previously-server-managed deployment will stamp the Astronomer-provided default as the requested value going forward
is that intentional? inspect.go:279-280 has the matching shift so the inspect template also bakes the effective identity in, which means inspect --template -> create --deployment-file round-trips pin the default too
longer-term, probably worth flagging back to the api team that the read model could expose the user-configured identity separately (or a flag indicating whether the effective value was user-set vs defaulted) so we can restore the prior nil-means-skip behavior. either way a short code comment noting the semantic difference would help future readers
jlaneve
left a comment
There was a problem hiding this comment.
lgtm, awesome cleanup. left one non-blocking note re the EffectiveWorkloadIdentity semantics shift, can be followed up separately
Summary
Retires the
astro-client-core(v1alpha1),astro-client-iam-core(iam/v1beta1), andastro-client-platform-core(platform/v1beta1) generated clients in favor of a single unifiedastro-client-v1client built from the publicversioned/v1.0spec released in astronomer/astro#37986.astro-client-v1/— unified client, tags for Organization/Workspace/Cluster/Deployment/Deploy/User/Team/ApiToken/Environment/Authorization/etc.astro-client-core/→astro-client-v1alpha1/, shrunk to IDE-only (Polaris Project,Polaris Sessiontags).astro-client-iam-core/,astro-client-platform-core/,cloud/platformclient/.private/v1alpha1/cli/auth-config(pkg/astroauth/config.go) and/v1alpha1/telemetry(pkg/telemetry/telemetry.go).Notable production fixes surfaced during migration
cloud/deployment/inspect/inspect.go: formatDeploymentEnvironmentVariable.UpdatedAtas RFC3339 before mapstructure decode (v1 changed the field fromstringtotime.Time; inspect was broken for any deployment with env vars).cmd/cloud/deployment.go: uppercase--cloud-providerinput before validating against theClusterCloudProviderenum (AWS/GCP/AZURE) so lowercase input keeps working.cloud/deploy/bundle.go: wire v1CreateDeployGitRequest(GITHUB + GENERIC providers) intoCreateDeployRequest.Gitnow that the v1 spec exposes it.cloud/deployment/deployment.go+cloud/deployment/fromfile/fromfile.go: stop synthesizing client-side defaults for optional deployment fields (scheduler size, hybrid scheduler AU/replicas, default worker queue, task-pod node pool). The server applies defaults; sending them from the CLI caused schema drift.scripts/patch-v1-gen/(Go): function-scope-aware rewrite ofoneOfdiscriminator setters that oapi-codegen (≤ v2.6.0) emits with untyped string literals into pointer fields.Test plan
go build ./...cleanmake lintcleango test ./...passeslocalhostcontext, organizationSample Organization, workspaceSample Workspace, clusterSample AWS Cluster):astro login localhost— v1/users/selfastro organization list/astro workspace listastro deployment list,astro deployment inspect <id>(full +--key),astro deployment logs <id>astro deployment create --type dedicated— confirmed server applies defaults (scheduler size MEDIUM, default worker queue, task-pod cpu/memory) that the CLI no longer synthesizesastro deployment update --description …— inspect confirms changeastro deployment inspect --template→astro deployment create --deployment-file(fromfile create), thenastro deployment update --deployment-file(fromfile update); env-varupdated_atdecoded correctly (RFC3339 mapstructure fix)astro deployment variable create/update/list(including--secret)astro deployment worker-queue create/update/deleteastro deployment token create/list/update/rotate/delete(identified by-t <name>)astro workspace token create/list/update/rotate/deleteastro organization token create/list/update/rotate/deleteastro organization team create/list/delete;astro workspace team add/update/list;astro deployment team add/update/list— exercises the newworkspaceId/deploymentIdquery params onGET /organizations/{orgId}/teamsastro organization user list/invite/update;astro workspace user add/update/remove/list;astro deployment user add/update/remove/listastro deployment delete— cleaned up both smoke deployments