Expliquer les mises à jour de dépendances Go
L'outil fourni nécessite Go 1.22 ou plus récent, et git pour --base. Il exécute go mod graph et go list -m -mod=readonly -json all sur chaque révision, avec GOWORK=off. Ces commandes lisent les fichiers go.mod du module et de ses dépendances ; elles ne construisent ni n'exécutent aucun code, et elles ne modifient pas go.mod ou go.sum.
1. Choisir les deux révisions
- Dans une pull request, l'ancien côté est la base de fusion :
git merge-base origin/main HEAD. N'utilisez le nom de la branche que si l'utilisateur le demande. --base REFlit les fichiersgo.modetgo.sumde ce commit avecgit archive, donc les modifications non validées dans l'arbre de travail constituent le nouveau côté. Utilisez--old DIR --new DIRpour deux répertoires.- Exécutez-le dans la racine du module (le répertoire contenant
go.mod), ou passez--new MODULE_DIR. Dans un dépôt avec plusieurs modules, exécutez-le une fois par module dont lego.moda changé.
2. L'exécuter
go run "${CLAUDE_PLUGIN_ROOT}/scripts/whybumped.go" --base "$(git merge-base origin/main HEAD)" --new MODULE_DIR
- Si la pull request indique ce qu'elle avait l'intention de modifier (un titre Dependabot tel que "Bump google.golang.org/grpc from 1.63.2 to 1.67.1"), passez-le avec
--expect google.golang.org/[email protected]. Alors tout autre changement est un AVERTISSEMENT, y compris les modules quego.moda augmentés de lui-même. - Ajoutez
--format jsonpour analyser le résultat. - Les dépendances doivent être dans le cache des modules ou téléchargeables depuis le proxy de modules dans l'environnement. Ne modifiez pas
GOPROXY,GOFLAGSouGONOSUMDBsauf si l'utilisateur le demande.
Codes de sortie
0 signifie aucun AVERTISSEMENT (ou --fail-on never). 1 signifie au moins un AVERTISSEMENT. 2 signifie que le résultat n'est pas fiable : le go.mod d'un côté est manquant, vide, tronqué, n'est pas un go.mod ou n'a pas de directive go ; go mod graph ou go list -m a échoué (souvent une entrée go.sum manquante, une version inconnue ou pas de réseau) ; leurs sorties sont en désaccord ; les deux côtés sont des modules différents ; un côté n'a aucune dépendance du tout ; ou la référence --base n'existe pas. Traitez 2 comme inconnu, jamais comme un succès, et montrez l'erreur à l'utilisateur.
Rapport
- Commencez par
go-raisedsi présent : l'ancienne et la nouvelle ligne go, la dépendance qui nécessite la nouvelle version et comment elle est entrée dans le graphe. Si go.mod est allé plus loin qu'aucune dépendance ne le nécessite, dites-le. - Regroupez les modifications de module par la ligne "pulled in through" : pour chaque module racine que
go.modexige, listez ce qu'il a augmenté ou ajouté. Ce sont les effets secondaires de cette mise à niveau. - Les modifications
requestedsont des versions que seulgo.moddemande. Pour un module// indirectqui est augmenté au-delà de ce qu'aucune dépendance ne nécessite, dites qu'il a été augmenté manuellement ou pargo get -u, et qu'il pourrait rester à la version nécessaire si l'utilisateur souhaite un changement plus petit. - Les modifications
loweredetremovedindiquent quel demandeur utilisait auparavant l'ancienne version et où ce demandeur est allé. Un module abaissé est une rétrogradation dans la construction ; mentionnez-le clairement. requirement-droppedsignifie que go.mod a perdu une ligne tandis que la construction a conservé la même version via un autre module.go mod tidyfait cela lorsqu'aucun paquet n'a besoin du module. Si l'utilisateur n'a pas exécuté tidy, vérifiez que go.mod n'a pas été endommagé.- Une chaîne passant par une version qui n'est pas sélectionnée est réelle : dans la sélection de version minimale, les exigences de chaque version dans le graphe comptent, même celles qui ont perdu face à une version plus récente.
- Ne modifiez pas
go.modsauf si l'utilisateur le demande. S'il souhaite un changement plus petit, la correction habituelle estgo get module@versionpour le module racine uniquement, puisgo mod tidy, et exécutez à nouveau l'outil.