Auto: Alcanzar el límite de velocidad de GH al generar un registro de cambios sobre una gran cantidad de confirmaciones

¿Alguna posibilidad de que pueda ver el repositorio para jugar?

wow, eso es un montón de solicitudes

Además, si pudiera obtener un registro más completo que podría ayudar

De hecho, fue capaz de recrear localmente. No necesito nada de ti más que esperanza 😉

Creamos muchas solicitudes similares en semantic-release , y no alcanzamos el límite de abuso, que yo sepa. Debe haber un tiempo de espera de 3 segundos entre las solicitudes que crean un comentario, ¿ve que eso sucede en sus registros?

Solo para estar seguro: ¿utiliza una única instancia de Octokit en todas estas solicitudes?

Estoy bastante seguro de que solo estamos creando 1.

Eso sucede aquí https://github.com/intuit/auto/blob/master/packages/core/src/git.ts#L123

que solo debe inicializarse una vez al inicio https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L1643

Aunque puedo comprobar

Verificado: solo creado una vez

Para probar este problema en automático:

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

Creo que esto está relacionado con https://github.com/octokit/plugin-throttling.js/issues/108 pero solo tenemos 1 instancia de octokit en ejecución, por lo que no deberíamos necesitar agrupar

¿Haces alguna solicitud GraphQL?

¿Puede confirmar que ve que los registros "superaron los límites de abuso" se producen a una velocidad de aproximadamente 1 cada 3 segundos?

Ah, eso podría ser. usamos @ octokit / graphql pero hoy vi que puedes hacerlo directamente a través de octokit. lo intentaré también

usamos @ octokit / graphql pero hoy vi que puedes hacerlo directamente a través de octokit

Sí, de esa manera comparte la misma configuración de solicitud y los ganchos del ciclo de vida de la solicitud

🙏

Bien corriendo ahora. Sin embargo, me queda una hora de espera en mi límite de tarifa 😢

@hipstersmoothie , puede usar nuestra instancia de github si está golpeando esto; estamos viendo lo mismo

¿Me pueden vincular al registro de compilación?

Le he enviado el registro de compilación, ya que se encuentra en un repositorio cerrado.

@vincentbriglia Estoy bastante seguro de que solucioné el problema en sus registros en # 1424

¿Podrías instalar la versión canary? Todo está bajo un alcance diferente, por lo que deberá reemplazar todos los nombres de los paquetes:

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 pudieras probar también, te lo agradecería!

Lo probé con

"@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",

sigue siendo un problema con el corredor de github GITHUB_TOKEN

intentando con un token personal ahora (he visto algunas discrepancias antes)

tampoco funcionó con un token personal.

Te di acceso al repositorio privado @hipstersmoothie - rama de la siguiente rama

¡Gracias! Pude resolver su problema bastante rápido. https://github.com/intuit/auto/pull/1424/commits/d6e7be20f17160d253298146b77648b408377890

Sin embargo, no creo que este sea el mismo problema que tiene

confirmó que eso solucionó el problema que estaba teniendo @hipstersmoothie : ¡tenga un buen fin de semana!

sin embargo @hipstersmoothie este cambio dejó de publicar y / o calcular correctamente las versiones de semver.

Creo que auto está comportando como se esperaba. Aludí a esto aquí . Esto se debe a que el complemento conventional commits trata todos los mensajes de confirmación que no son de semver como skip-release (ex: chore, docs, etc.).

Este es el PR que lo implementó https://github.com/intuit/auto/pull/1086

¿Preferiría que el complemento de confirmación convencional no hiciera esto? (por ejemplo: no te saltes para doc / chore / etc)

@vincentbriglia Estoy bastante seguro de que solucioné el problema en sus registros en # 1424

¿Podrías instalar la versión canary? Todo está bajo un alcance diferente, por lo que deberá reemplazar todos los nombres de los paquetes:

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 pudieras probar también, te lo agradecería!

Lo probaré hoy y me pondré en contacto contigo.

@hipstersmoothie, esto sigue siendo un problema al generar un registro de cambios.

Así que todo parecía funcionar cuando tenía el indicador --no-changelog. Sin embargo, me lo quité y solo intentamos usar auto shipit en el CI y falla con el mismo error de límite de frecuencia.

@hipstersmoothie Agregué un poco más de contexto ☝️

@hipstersmoothie muchas gracias por investigar esto. Creo que los lanzamientos recientes han solucionado esto. Seguiré adelante y cerraré esto. auto está funcionando bastante bien ahora. Gracias de nuevo