Auto: Atteindre la limite de débit GH lors de la génération du journal des modifications sur un très grand nombre de commits

Y a-t-il une chance que je puisse voir le repo pour jouer avec ?

wow ça fait beaucoup de demandes

Aussi, si je pouvais obtenir un journal plus complet qui pourrait aider

Était en fait capable de recréer localement. Je n'ai besoin de rien de ta part d'autre que de l'espoir

Nous créons beaucoup de demandes similaires dans semantic-release , et nous n'avons pas atteint la limite d'abus, pas que je sache. Il devrait y avoir un délai d'attente de 3 secondes entre les demandes qui créent un commentaire, voyez-vous cela se produire dans vos journaux ?

Juste pour être sûr : utilisez-vous une seule instance Octokit pour toutes ces requêtes ?

Je suis presque sûr que nous ne créons que 1.

Cela se passe ici https://github.com/intuit/auto/blob/master/packages/core/src/git.ts#L123

qui ne doit être initialisé qu'une seule fois au démarrage https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L1643

je peux vérifier quand même

Vérifié : créé une seule fois

Pour tester ce problème en automatique :

yarn
yarn build
yarn auto changelog --from v1.0.0 -d

Je pense que cela est lié à https://github.com/octokit/plugin-throttling.js/issues/108 mais nous n'avons qu'une instance d'octokit en cours d'exécution, nous ne devrions donc pas avoir besoin de cluster

faites-vous des requêtes GraphQL ?

Pouvez-vous confirmer que vous voyez les journaux "dépasser les limites d'abus" se produire à un taux d'environ 1 toutes les 3 secondes ?

Ah c'est peut-être ça. nous utilisons @octokit/graphql mais j'ai vu aujourd'hui que vous pouvez le faire directement via octokit. va essayer ça aussi

nous utilisons @octokit/graphql mais j'ai vu aujourd'hui que vous pouvez le faire directement via octokit

Oui, de cette façon, il partage les mêmes paramètres de demande et les mêmes crochets de cycle de vie de demande

🙏

D'accord en cours d'exécution maintenant. Il me reste une heure sur mon taux d'attente limite 😢

@hipstersmoothie, vous pouvez utiliser notre instance github si vous rencontrez cela - nous voyons la même chose

Pouvez-vous me lier au journal de construction?

Je vous ai envoyé le journal de construction, car il s'agit d'un dépôt fermé.

@vincentbriglia Je suis presque sûr d'avoir résolu le problème dans vos journaux en #1424

Pourriez-vous installer la version Canary ? Tout est sous une portée différente, vous devrez donc remplacer tous les noms de package :

yarn add @auto-canary/[email protected]

yarn add @auto-canary/[email protected]
yarn add @auto-canary/[email protected]
yarn add @auto-canary/[email protected]
yarn add @auto-canary/[email protected]

@dariye Si vous pouviez essayer de tester aussi, je l'apprécierais !

Essayé avec

"@auto-canary/all-contributors": "9.49.2-canary.1424.17767.0",
"@auto-canary/auto": "9.49.2-canary.1424.17767.0",
"@auto-canary/conventional-commits": "9.49.2-canary.1424.17767.0",
"@auto-canary/first-time-contributor": "9.49.2-canary.1424.17767.0",
"@auto-canary/npm": "9.49.2-canary.1424.17767.0",
"@auto-canary/released": "9.49.2-canary.1424.17767.0",

toujours un problème avec le github runner GITHUB_TOKEN

essayer avec un jeton personnel maintenant (j'ai déjà vu quelques écarts)

ne fonctionnait pas non plus avec un jeton personnel.

Je vous ai donné accès au dépôt privé

Merci! A pu résoudre votre problème assez rapidement. https://github.com/intuit/auto/pull/1424/commits/d6e7be20f17160d253298146b77648b408377890

Je ne pense pas que ce soit le même problème que @dariye .

a confirmé que cela réglait le problème que j'avais

cependant @hipstersmoothie ce changement a maintenant cessé de publier et/ou de calculer correctement les versions de semver.

Je pense que auto se comporte comme prévu. J'y ai fait allusion ici . C'est parce que le plugin conventional commits traite tous les messages de commit non-semver comme skip-release (ex: corvée, docs, etc.).

C'est le PR qui l'a mis en œuvre https://github.com/intuit/auto/pull/1086

Préféreriez-vous que le plugin de commit conventionnel ne le fasse pas ? (par exemple : ne pas sauter pour la doc/la corvée/etc)

@vincentbriglia Je suis presque sûr d'avoir résolu le problème dans vos journaux en #1424

Pourriez-vous installer la version Canary ? Tout est sous une portée différente, vous devrez donc remplacer tous les noms de package :

yarn add @auto-canary/[email protected]

yarn add @auto-canary/[email protected]
yarn add @auto-canary/[email protected]
yarn add @auto-canary/[email protected]
yarn add @auto-canary/[email protected]

@dariye Si vous pouviez essayer de tester aussi, je l'apprécierais !

Je teste ça aujourd'hui et je reviens vers vous.

@hipstersmoothie c'est toujours un problème lors de la génération d'un changelog.

Donc, tout semblait fonctionner lorsque j'avais le drapeau --no-changelog. Cependant, je l'ai enlevé et nous essayons simplement d'utiliser auto shipit dans le CI et cela échoue avec la même erreur de limite de débit.

@hipstersmoothie j'ai rajouté un peu plus de contexte ☝️

@hipstersmoothie merci beaucoup pour votre recherche. Je pense que les versions récentes ont corrigé cela. Je vais aller de l'avant et fermer ceci. auto fonctionne plutôt bien pour nous maintenant. Merci encore