| name | update-azure-deps |
| description | Bump Microsoft Azure SDK Go dependencies in the azure provider to their latest stable major versions, audit CHANGELOGs for breaking changes and deprecations, and patch our call sites. Triggers on requests like "update azure deps", "bump azure SDK versions", "upgrade azure provider dependencies", "check for new azure SDK majors". |
| argument-hint | [provider go.mod path] (defaults to providers/azure/go.mod) |
Update Azure SDK Go Dependencies
Bump every github.com/Azure/... and github.com/AzureAD/... dep in a provider's go.mod to its latest stable major, audit CHANGELOGs for breaking changes that don't surface as compile errors, and patch the call sites.
This skill exists because the naïve approach burns thousands of tokens on shell-escaping the proxy-encoded !azure path, retrying probes, classifying beta vs stable vs pseudo by hand, and reading every CHANGELOG inline. The bundled scripts collapse all of that into two commands.
Workflow
1. Branch off main first
git checkout -b update-azure-deps main
Don't pile dep bumps onto an unrelated feature branch. If the user is on a feature branch with uncommitted work, ask before stashing.
2. Probe what's bumpable
python3 .claude/skills/update-azure-deps/probe.py providers/azure/go.mod
Output is one line per Azure dep, classified:
UP <path>@<old> -> <newpath>@<new> — a stable upgrade (patch, minor, or new major) is available. Apply it.BETA <path>@<ver> (new major only as v2.0.0-beta.3; staying) — a higher major exists but only as beta or pseudo-version. Skip it by default. Mention it to the user separately so they can decide.OK <path>@<ver> — already on the latest stable. No action.
The script defaults to stable-only (no betas, no pseudo-versions). It probes up to 5 majors above the current path in parallel, with early-stop on the first missing major (Azure SDK majors are sequential). Expect 1–3 minutes for ~45 deps depending on proxy.golang.org latency. Run it in the background and continue with other prep work.
Encoding note (so you don't reinvent it): proxy.golang.org requires capital letters in module paths to be escaped as !lowercase, so Azure becomes !azure. The script handles this; if you ever need to probe by hand, use printf '\x21' to emit ! from bash without history-expansion problems, or just call the script.
3. Get user sign-off on the upgrade list
Show the user the UP rows and call out any BETA rows. Default recommendation: apply all UP rows (stable-only). Ask before pulling in any beta unless they explicitly asked for cutting-edge.
4. Audit CHANGELOGs for each module crossing a major
For every UP row where the major number changed (e.g. v1 → v2, or /v9 → /v10):
python3 .claude/skills/update-azure-deps/changelog.py \
github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/operationalinsights/armoperationalinsights \
v1.2.0 v2.0.2
This prints every CHANGELOG section released strictly after v1.2.0 and up to v2.0.2, covering every release crossed (including any betas of the new major if they preceded the GA). Read the Breaking Changes subsections.
You don't need to run this for patch or minor bumps — those are guaranteed non-breaking by SDK policy.
5. Watch for these silent breaking-change patterns
These compile cleanly but produce wrong behavior. The Azure SDK Go uses them often when refactoring a module across majors:
| Pattern | Fix |
|---|
Date field changed from *string to *time.Time (e.g. WorkspaceProperties.CreatedDate) | Replace parseAzureDateString(x) (or any *string-consuming helper) with llx.TimeDataPtr(x) at the call site |
Capacity/level changed from *EnumType to *int32 or *int64 | Existing int64(*v) casts keep working — but verify the field is still on the same struct |
*Identity renamed to *ManagedServiceIdentity | If we use convert.JsonToDict(x.Identity), no change needed; if we type-assert, fix the type |
Operation flipped from sync to LRO (Update → BeginUpdate) | Compile error catches this; replace with the Begin* form and add .PollUntilDone(ctx, nil) |
Subpackage extracted (e.g. container registry Tasks moved to armcontainerregistrytasks) | Compile error catches this; add the new package to go.mod and import |
Field removed from a struct (e.g. RegistryProperties.AutoGeneratedDomainNameLabelScope) | Compile error catches this; drop the field from our CreateResource call |
6. Update import paths and go.mod
For each UP row crossing a major:
grep -l '"github.com/Azure/.../armcontainerregistry"' providers/azure -r
Update providers/azure/go.mod to match: replace armcontainerregistry v1.2.0 with armcontainerregistry/v3 v3.0.0.
Patch and minor bumps inside the same major don't need import path changes — only the version string in go.mod.
7. Resolve modules
cd providers/azure && go mod tidy
go mod tidy may hit a TLS error on proxy.golang.org/sumdb/sum.golang.org/supported inside the sandbox. If you see tls: failed to verify certificate: x509: OSStatus -26276, retry the same command with dangerouslyDisableSandbox: true. Don't set GOSUMDB=off — preserve sum verification.
8. Build, vet, test
cd providers/azure && go build ./... && go vet ./... && go test ./resources/...
If go build fails, the breaking change is one of the patterns from step 5 — fix the call site and rebuild.
9. Verify formatting
gofmt -l providers/azure/resources/<changed-file>.go
Should print nothing.
10. Show the diff and stop
Summarize for the user:
- Which deps were bumped (with old → new majors).
- Which betas exist but were skipped.
- Which call-site changes were required because of breaking changes.
- Build/test status.
Do not commit. The user's general rule: don't commit unless explicitly asked. Don't bump the provider's Version field in config/config.go either — that's part of the release flow, not the dep-bump flow.
When this skill applies
- "update azure deps", "bump azure SDK versions", "upgrade azure provider dependencies"
- "check for new azure SDK majors"
- Any request to refresh
github.com/Azure/... packages
When it doesn't apply
- Updating a single non-Azure dep (e.g.
cockroachdb/errors) — just go get x@latest.
- Releasing a provider version (the
version flow in provider-release skill).
- AWS/GCP SDK updates — same shape but the proxy doesn't need the
! escaping (no capital letters in their module paths) and the CHANGELOG locations differ.
Common gotchas
go mod tidy removed an entry I just added. You ran it from the wrong directory. The Azure provider has its own go.mod. cd providers/azure first, then go mod tidy.bash shows \!azure in a URL. History expansion. Either use printf '\x21' for !, run inside bash -c '...' (which still expands), or use Python (which the bundled scripts do).- The probe says
BETA but the user asked for "latest". Confirm with them — "latest stable" and "latest period" are different policies, and betas of new Azure SDK majors typically churn API for months before GA.
- CHANGELOG fetch fails with "Bad credentials". The
gh CLI is reading a stale GITHUB_TOKEN env var. The bundled changelog.py uses raw GitHub URLs and doesn't need auth, so just use it.
- The new major doesn't have a
CHANGELOG.md yet. Some pre-GA Azure SDKs haven't generated one. changelog.py will 404; fall back to git log on the SDK repo with gh, or read the diff between the two tags directly.
