Terraform-aws-github-runner: Scale Up lambda ne signale aucune erreur mais ne lance pas de nouveau coureur

Je vois la même chose de mon côté et je soupçonne que cela est lié au récent incident de dégradation des performances pour les actions GitHub.

Lorsque nous avons essayé de filtrer la liste des workflows en file d'attente sur notre dépôt, nous avons obtenu l'erreur suivante et une liste vide lorsqu'il y a clairement des workflows en file d'attente :
We are having problems searching workflow runs. The results may not be complete.

Je pense que le lambda s'appuie sur cela pour renvoyer les flux de travail en file d'attente pour lancer une instance.

Voir exactement la même chose fwiw.

J'essayais de comprendre s'il existe un moyen simple de forcer manuellement une mise à l'échelle. Il semble que la configuration inactive ne soit vérifiée que lors des réductions d'échelle ? Je ne connais pas le code, j'ai donc peut-être raté quelque chose.

J'ai passé un peu de temps sur un problème similaire, j'ai constaté que les balises requises pour mon EC2 par Policy le faisaient échouer. J'ai pu le trouver en regardant les erreurs de l'API CloudTrail.

Merci pour les réponses jusqu'à présent, tout le monde.

@rlove Je ne trouve rien dans Cloudtrail suggérant que la mise à l'échelle lambda fait quoi que ce soit, erreur ou autre.
@samgiles Oui, c'était aussi quelque chose que j'étudiais; Je ne pouvais pas (en un temps limité, certes) créer un événement test qui forcerait le scale-up lambda à agir.
@ eky5006 Cela aurait du sens, mais je vois toujours le même problème et selon https://www.githubstatus.com/incidents/xn0sd2x4nd7f le problème est résolu. Voyez-vous mieux de votre côté ?

J'ai le même problème.
INFO Repo < repo name > has 0 queued workflow runs même s'il y a des travaux en file d'attente. Et cette API https://docs.github.com/en/rest/reference/actions#list -workflow-runs-for-a-repository renvoie correctement les flux de travail en file d'attente.
Cela a commencé hier et ne fonctionne toujours pas.

INFO Repo < repo name > has 0 queued workflow runs

@bartoszjedrzejewski Où voyez-vous cette sortie ?

@rjcoupe dans les journaux cloudwatch à grande échelle. Tu es sur quelle version ? Je pense que c'est parce que je suis sur 0.8.1. J'essaie de mettre à jour en ce moment. Mon collègue n'a pas ce problème, il est sur 0.10

J'ai eu le même problème, la panne a laissé des coureurs inscrits persistants. Je les ai désinscrits de mon organisation GitHub et maintenant les coureurs évoluent comme prévu.

J'espère que cela aide quelqu'un.

La mise à jour de lambdas de 0.8.1 à 0.11.0 a résolu mon problème.

Salut, Nous avons eu le même problème hier et la mise à niveau de lambdas de 0.8.1 à 0.10.0 l'a également résolu.

J'étais sur la v0.10.0 donc je n'avais pas beaucoup d'espoir, mais la v0.11.0 semble résoudre le problème. Bizarre!

@gertjanmaas n'importe quelle idée, ressemble à la panne d'hier.

Cela pourrait être lié à la panne d'hier. Dans notre cas, certains référentiels n'ont pas envoyé d'événement au webhook, ce qui a entraîné la mise en file d'attente des tâches et la création d'aucune instance, mais cela aurait pu affecter l'une des API que nous utilisons.

La panne a été corrigée, donc si c'était la cause, cela devrait être résolu.

Non, cela se reproduit depuis ce matin sans aucune modification apportée aux ressources AWS. Il semble que le comportement correct était un coup de chance.

Je viens d'apprendre que nous avons vu des problèmes par intermittence avec toutes les actions d'aujourd'hui, pas seulement avec les coureurs dynamiques auto-hébergés. Je pense qu'il y a des problèmes de stabilité sur GitHub.