fix(kubernetes): republish with correct upgrade chain (2026.06.10.1) #50
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "worktree-reflective-napping-quasar"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
2026.06.05.1→2026.06.10.12026.05.27.2→2026.06.04.1→2026.06.04.2→2026.06.05.1→2026.06.10.1BundleBuildFailedon all 15 model types after pulling@swamp/kubernetesfrom the registryRoot cause
The published registry artifact
2026.06.05.1contained stale model files (version2026.06.04.1with upgrades ending at2026.05.27.2). The fix landed on main but the manifest version wasn't bumped, so CI never republished.Test plan
deno check,deno lint,deno fmt,deno install --frozen— all pass@swamp/kubernetes@2026.05.27.2, created a model instance, swapped to local2026.06.10.1sourceswamp model getauto-upgraded typeVersion from2026.05.27.2→2026.06.10.1swamp doctor extensions— 15/15 Indexed, OVERALL: PASSswamp model validate— 5/5 passedswamp extension quality manifest.yaml— 14/14 rubric, packaging succeeded.tar.gzand verified all 15 bundled.jsfiles haveversion: "2026.06.10.1"with the full upgrade chain🤖 Generated with Claude Code
Adversarial Review
This PR bumps all 15 Kubernetes model versions from
2026.06.05.1to2026.06.10.1and appends a corresponding upgrade entry to each model'supgradesarray. The manifest version is also bumped to match.Analysis
Every changed file follows the same mechanical pattern:
versionfield updated from"2026.06.05.1"to"2026.06.10.1"toVersion: "2026.06.10.1", identityupgradeAttributes: (old) => old, and a description noting no behavior changemanifest.yamlversion matches the model versionsVerified:
2026.05.27.2→2026.06.04.1→2026.06.04.2→2026.06.05.1→2026.06.10.1manifest.yamlagree on2026.06.10.1(old: Record<string, unknown>) => oldis correct for a no-schema-change bumpNo security, correctness, concurrency, resource management, or data integrity concerns. There is no new logic to break.
Verdict
PASS — Mechanical version bump with correct upgrade chain entries across all 15 Kubernetes models. No code, schema, or behavior changes.
Code Review
This PR bumps all 15 kubernetes extension models from
2026.06.05.1to2026.06.10.1and adds the corresponding upgrade entry to each model'supgradesarray. Themanifest.yamlversion is updated consistently. No functional code changes are present — this matches the legitimate "version bump to republish with correct upgrade chain" pattern described in CLAUDE.md.Blocking Issues
None.
Suggestions
event.ts— fieldSelector string interpolation from user-supplied names (getForPod,getForDeployment,getForService): ThepodName,deploymentName, andserviceNameargs are interpolated directly into thefieldSelectorstring (e.g.`involvedObject.name=${args.podName},involvedObject.kind=Pod`). A crafted name containing a comma could inject additional fieldSelector conditions (e.g.my-pod,involvedObject.kind=Deployment). In practice the K8s API rejects malformed fieldSelectors and Kubernetes resource names don't allow commas, so this is not exploitable — but consider validating names or using the Kubernetes client's structured filter API if available.node.ts— same fieldSelector interpolation ingetPodsOnNode:`spec.nodeName=${args.nodeName}`has the same pattern.pod.ts— exec method doesn't support per-call namespace override: Every other method resolves namespace asargs.namespace ?? context.globalArgs.namespace, butexecuses onlyglobalArgs.namespace. This is inconsistent and may surprise callers who expect to exec into a pod in a different namespace.namespace.ts— health method marks scaled-to-zero deployments unhealthy:ready: replicas > 0 && replicas === readyalways evaluates tofalsewhenreplicas === 0. An intentionally scaled-down deployment will cause the overallhealthyflag to befalse. Consider whetherreplicas === 0should be treated as a special "scaled down intentionally" case.