// Diagnose and unblock failed Dependabot pull requests in cloud-provider-azure by classifying CI failures, syncing Go modules, retesting quota-flaked e2e jobs, and updating PR status. Use when a Dependabot PR fails go-mod-consistency, pull-cloud-provider-azure-e2e jobs, or dependency/toolchain CI.
| name | unblock-dependabot-pr |
| description | Diagnose and unblock failed Dependabot pull requests in cloud-provider-azure by classifying CI failures, syncing Go modules, retesting quota-flaked e2e jobs, and updating PR status. Use when a Dependabot PR fails go-mod-consistency, pull-cloud-provider-azure-e2e jobs, or dependency/toolchain CI. |
Use this skill when a Dependabot PR in cloud-provider-azure has failed CI and
the user wants the agent to unblock it with the smallest safe action.
Expected inputs:
gh pr view <pr> --json number,title,headRefName,headRepositoryOwner,headRefOid,baseRefName,author,labels,mergeable,statusCheckRollup
gh pr checks <pr>
gh pr checkout <pr>
git status --short
Stop and report a conflict if unrelated uncommitted changes exist. Do not stage or overwrite unrelated files.
Use the shared sync-go-modules skill from this repo.
.agents/skills/sync-go-modules/SKILL.md.--allow-dirty as that skill describes.git diff --stat
git status --short
git add <specific go.mod/go.sum/vendor files>
git diff --cached --stat
git commit -m "Update Go modules"
git push
/lgtm on the PR:gh pr comment <pr> --body "/lgtm"
The push reruns CI. Do not add /retest just for the old failed
go-mod-consistency run after pushing a new commit.
Use this path only when the failed jobs are exclusively
pull-cloud-provider-azure-e2e-* jobs and the failing logs show one of:
PublicIPCountLimitReachedPublicIPPrefixCountLimitReachedConfirm the failure text from the job logs before retesting. If any non-e2e job also failed, handle that failure separately before blanket retesting.
Retest options:
gh pr comment <pr> --body "/test <job-name>"
Use one /test <job-name> comment per failed e2e job when you want a narrow
rerun. Use /retest only when all current failed jobs are safe to rerun:
gh pr comment <pr> --body "/retest"
If you are already pushing a commit for another fix, prefer the push-triggered CI rerun instead of adding a separate retest comment.
Discuss these with the user before changing code or CI policy:
golangci-lint or Analyze (go) fails with a Go toolchain mismatch, such as
panic: file requires newer Go version ... (application built with ...)golangci-lint typecheck failures after an Azure SDK or Kubernetes module
bumparmcompute/v6 consumers in a PR
that updated packages to armcompute/v7k8s.io/api,
k8s.io/apimachinery, and k8s.io/client-go moving ahead of the rest of the
Kubernetes dependency setdependency-review, vulnerability, or license failures where the resolution
may require accepting risk, excluding a finding, or changing the dependency
versionneeds-rebase or mergeable reports CONFLICTINGFor dependency, toolchain, and policy failures, collect the failing job names, the smallest representative log snippets, current dependency versions, and a proposed narrow fix. Ask before changing linter policy, broadening a dependency bump, or editing generated Dependabot PR metadata.
If the PR still needs a rebase after other common blockers have been fixed, ask Dependabot to rebase the branch instead of manually rewriting the generated PR branch:
gh pr comment <pr> --body "@dependabot rebase"
Do this after local fixes and pushes are complete so Dependabot rebases the latest branch state.
git add ../lgtm after a successful module-sync push when the PR is otherwise ready
for review.@dependabot rebase rather than manually force-pushing a rebase./retest only for failures already classified as transient or safe to
rerun.Synchronize all tracked Go modules with the go-mod-consistency CI and refresh the root vendor tree. Use when go-mod-consistency fails, dependency bumps leave go.mod or go.sum stale, or the user asks to unblock module consistency, tidy all modules, or update vendor for the main module.
Generate or update the documentation-site release note for a given tag, commit it on a branch, push it to a writable remote, and open a GitHub PR to the docs branch. Use when the user wants to create or update release notes, generate a changelog for a tag, or mentions release notes, docs PR, or documentation for a release.
Prepare and publish a stable release in two phases by reusing the shared release-tag and release-note-doc-pr skills, building artifacts in GitHub, generating release notes and draft releases locally, validating release assets, and controlling latest-release status explicitly. Use when the user wants to perform a full release, publish a new version, or mentions releasing, shipping a version, or the end-to-end release process.
Scan a built container image with Trivy, classify fixable Go-module and base-image CVEs, apply dependency and Dockerfile fixes, and verify the result with file checks and an optional image rescan. Use when the user wants to fix CVEs in a container image, scan for vulnerabilities, or mentions Trivy, CVE remediation, image security, or dependency vulnerabilities.
Cherry-pick a merged pull request onto a release branch with Prow-style branch naming, manual conflict resolution, targeted validation, and GitHub PR creation. Use when the user wants to backport a PR, cherry-pick a commit to a release branch, or mentions cherry-pick, backport, or porting a fix to an older release.
Create and optionally push the next Kubernetes-style release tag (vX.Y.Z) from a release-X.Y branch by resolving the remote branch tip, computing the next patch tag, and tagging the commit directly without checking out the branch. Use when the user wants to tag a release, create a version tag, or mentions release tagging, cutting a release, or bumping a patch version.