Terraform-aws-github-runner: Scale Up Lambda meldet keine Fehler, startet aber keinen neuen Runner

Ich sehe dasselbe auf meiner Seite und vermute, dass es mit dem jüngsten Vorfall mit verminderter Leistung für GitHub-Aktionen zusammenhängt.

Beim Versuch, die Liste der Workflows in der Warteschlange in unserem Repository zu filtern, haben wir den folgenden Fehler und eine leere Liste erhalten, wenn eindeutig Workflows in der Warteschlange vorhanden sind:
We are having problems searching workflow runs. The results may not be complete.

Ich denke, das Lambda verlässt sich darauf, um Workflows in der Warteschlange zurückzugeben, um eine Instanz hochzufahren.

Sehen Sie genau das gleiche fwiw.

Ich habe versucht herauszufinden, ob es eine einfache Möglichkeit gibt, eine Skalierung manuell zu erzwingen. Es scheint, als ob die Leerlaufkonfiguration nur während des Herunterskalierens überprüft wird? Ich bin mit dem Code nicht vertraut, also habe ich vielleicht etwas übersehen.

Ich verbrachte ein wenig Zeit mit einem ähnlichen Problem und stellte fest, dass die erforderlichen Tags für mein EC2 by Policy dazu führten, dass es fehlschlug. Ich konnte es finden, indem ich mir die CloudTrail-API-Fehler ansah.

Danke für die bisherigen Antworten an alle.

@rlove Ich kann in Cloudtrail nichts finden, was darauf hindeutet, dass das Scaleup-Lambda überhaupt etwas tut, Fehler oder anderes.
@samgiles Ja, das war etwas, was ich auch untersucht habe; Ich konnte (zugegebenermaßen in begrenzter Zeit) kein Testereignis erstellen, das das Scaleup-Lambda in Aktion zwingen würde.
@eky5006 Das würde Sinn machen, aber ich sehe immer noch das gleiche Problem und laut https://www.githubstatus.com/incidents/xn0sd2x4nd7f ist das Problem behoben. Sehen Sie an Ihrem Ende besser?

Ich habe das gleiche Problem.
INFO Repo < repo name > has 0 queued workflow runs , obwohl Jobs in der Warteschlange stehen. Und diese API https://docs.github.com/en/rest/reference/actions#list -workflow-runs-for-a-repository gibt Workflows in der Warteschlange ordnungsgemäß zurück.
Gestern fing es an und funktioniert immer noch nicht.

INFO Repo < repo name > has 0 queued workflow runs

@bartoszjedrzejewski Wo siehst du diese Ausgabe?

@rjcoupe beim Hochskalieren von Cloudwatch-Protokollen. Auf welcher Version bist du? Ich denke, es liegt daran, dass ich auf 0.8.1 bin. Ich versuche gerade zu aktualisieren. Mein Kollege hat dieses Problem nicht, er ist auf 0.10

Ich hatte das gleiche Problem, der Ausfall hinterließ einige verweilende registrierte Läufer. Ich habe sie von meiner GitHub-Organisation abgemeldet und jetzt skalieren die Runner wie erwartet.

Hoffe das hilft jemandem.

Das Aktualisieren von Lambdas von 0.8.1 auf 0.11.0 hat mein Problem behoben.

Hallo, wir hatten gestern das gleiche Problem und das Upgrade von Lambdas von 0.8.1 auf 0.10.0 hat es auch gelöst.

Ich war auf v0.10.0, also hatte ich nicht viel Hoffnung, aber v0.11.0 scheint das Problem zu beheben. Bizarr!

@gertjanmaas irgendeine Idee, sieht aus wie der gestrige Ausfall.

Könnte mit dem Ausfall gestern zusammenhängen. In unserem Fall haben bestimmte Repositorys kein Ereignis an den Webhook gesendet, was dazu führte, dass Jobs in die Warteschlange gestellt und keine Instanz erstellt wurde, aber es hätte sich auf alle von uns verwendeten APIs auswirken können.

Der Ausfall wurde behoben. Wenn dies also die Ursache war, sollte dies behoben werden.

Nein, es passiert seit heute Morgen wieder, ohne dass Änderungen an den AWS-Ressourcen vorgenommen wurden. Scheint, das richtige Verhalten war ein Zufall.

Ich habe gerade erfahren, dass wir heute bei allen Aktionen ab und zu Probleme gesehen haben, nicht nur bei den dynamischen, selbst gehosteten Läufern. Ich denke, es gibt Stabilitätsprobleme auf GitHub.