add missing serverless and template update flags

[vavo]

E-252: add missing serverless and template update flags

• resolves the remaining cli gaps from feat: add missing flags for serverless/template management #252 by adding runpodctl serverless update --template-id and runpodctl template update --container-disk-in-gb.
• maintains full legacy command compatibility (stderr warnings only, stdout unchanged).
• keeps runpodctl as the primary binary; drop-in upgrade for existing users.
• updates endpoint template swapping through the existing graphql mutation path and extends template update requests to include container disk size.
• adds unit coverage for the new flags and request paths, and updates generated docs for the affected commands.
• note: the other two report items in feat: add missing flags for serverless/template management #252 are already present/working on current main:
  • runpodctl serverless create --network-volume-id already exists
  • runpodctl template create --volume-mount-path already works; i live-verified /models persisted on create/get

Test plan:

• go test ./...
• go test -tags e2e ./e2e
• live verify template update --container-disk-in-gb on a disposable template, then delete it
• live verify serverless update --template-id on a disposable endpoint with two disposable serverless templates, then delete all resources

[promptless]

Promptless prepared a documentation update related to this change.

Triggered by PR #266

Added documentation for the --template-id flag on serverless update (swap templates on existing endpoints) and the --container-disk-in-gb flag on template update (update container disk size).

Review at https://app.gopromptless.ai/suggestions/01df3d1e-6473-4dd2-b512-9ad14493bf3a

[TimPietruskyRunPod]

thanks for this — the serverless update --template-id and template update --container-disk-in-gb flags are genuinely useful additions. this is complementary to #271 (which adds flags to create commands, not update), so no overlap.

a few things to address:

partial update on failure
if the REST update succeeds but the GraphQL --template-id call fails, the endpoint is left partially updated with no rollback or warning. at minimum, print a warning to stderr saying the REST fields were updated but the template swap failed.

container-disk-in-gb zero-value problem
the ContainerDiskInGb field uses int with omitempty in the JSON tag. setting it to 0 would silently omit it from the request. if 0 is a valid value the user might want to send, this is a bug. consider using *int or removing omitempty.

double error reporting
runUpdate calls output.Error(err) and then returns fmt.Errorf(...). cobra will also handle the returned error, so the user sees the error twice. pick one path.

e2e testing
please verify against the live api — create an endpoint, update its template-id, confirm the change in the response, clean up.

this can merge alongside #271 with minor conflict resolution on endpoints.go whitespace. looking forward to it.

[vavo]

Hi Tim, thanks for the review, I'll fix the PR when I get a chance.

regarding e2e tests - for some reason I've though this is something you run as part of the review. From now on I'll include them as part of the PRs.

[vavo]

Hi Tim, went through the follow-up items and updated the branch. Let me know if I forgot something.

changes made:

• added a stderr warning for the partial-update case where the rest endpoint update succeeds but the graphql template swap fails
• changed template update request handling so container-disk-in-gb is sent explicitly when set, including 0
• removed the duplicate local error output in the updated commands so errors are surfaced once

verification:

• go test ./cmd/serverless ./cmd/template ./internal/api
• added unit coverage for graphql error handling, the partial-update warning path, and container-disk-in-gb=0
• live e2e verification passed against the api:
  • created a disposable serverless template and updated container-disk-in-gb from 20 to 21
  • created a second disposable serverless template
  • created a disposable cpu endpoint from the first template
  • updated the endpoint with --template-id to the second template
  • confirmed the endpoint reported the new template id afterward
  • deleted the endpoint and both templates, then verified they were gone

[TimPietruskyRunPod]

thanks for addressing all the feedback — the partial-update warning, the *int fix for container-disk-in-gb, and removing the duplicate error output all look good.

one last thing: if the user runs serverless update <id> without passing any flags, the command silently succeeds and just prints the current endpoint state. it would be better to return an error like "no update flags specified" so the user knows they forgot to specify what to update. same applies to template update.

once that's in, this is good to go.