Terraform-aws-github-runner: Hochskalieren von Lambda fehlgeschlagen

Ich hatte den gleichen Fehler, versuchen Sie, der App-Rechte für die Gruppe "Aktionen" zu geben.

@adrianmiron Hast du es

gleiches Problem +1

@npalm Könnten Sie mir bitte helfen?

@adrianmiron Ich habe die Actions-Gruppe ausprobiert, habe aber immer noch

Ich erkenne das Problem nicht Das Scale-Up-Lambda holt eine Nachricht aus der Warteschlange, als nächstes prüft es, ob noch Jobs in der Warteschlange vorhanden sind. Wenn ja, wird es hochskaliert. Das Hochskalieren-Lambda wird für Nachrichten ausgelöst, die sich 30 Sekunden lang in der Warteschlange befinden. Die Fehlermeldung gibt an, dass das Lambda die API nicht aufrufen darf.

Bitte überprüfen Sie, ob Ihre GitHub-App gemäß der Dokumentation eingerichtet ist. Da Ihr Scale-Up-Lambda ausgelöst wird, scheint die App für das Repository installiert zu sein, ansonsten sollte kein Ereignis empfangen werden. Die meisten ligical sieht also so aus, als wären die Berechtigungen nicht richtig eingestellt.

@manoj-k-deepr Bei meinen Untersuchungen des gleichen Fehlers stellte sich heraus, dass es sich um Berechtigungsprobleme der Github-App handelte (die tatsächlich die Abfrage der Repo-Aktionen durchführt. Ich erinnere mich, dass ich über die Lambda -> Github-App gegangen bin Sache 5 mal und es war nicht.

Teilen Sie einen Druckbildschirm mit Berechtigungen für Organisation/Repo und ich werde morgen früh vergleichen.

@npalm ja, es ist ein Problem mit Erlaubnis. Ich habe das Problem behoben, indem ich selbst gehosteten Läufern Zugriff ( Lesen und Schreiben ) in der Organisation bereitgestellt habe. In den Dokumenten wird nichts über die Runner-Berechtigung erwähnt.

Es gab ein Problem mit den Github-App-Berechtigungen. @npalm Können Sie die Dokumentation aktualisieren und angeben, welche Berechtigungsanwendung erforderlich ist

@mkryva Toll, dass es funktioniert. Ich lasse das Problem offen, damit wir die Dokumente aktualisieren können. PR's zur Verbesserung der Dokumentation sind immer willkommen!

Nach dem Aktualisieren der Berechtigungen schlägt es mit folgendem Fehler fehl:

ERROR AuthFailure.ServiceLinkedRoleCreationNotPermitted: The provided credentials do not have permission to create the service-linked role for EC2 Spot Instances.

UPD: Anscheinend war der Grund "Sie haben Ihr Kontingent für die maximalen Spot-Flottenanfragen für dieses Konto erreicht".

Skalieren Sie Lambda, das für mich fehlschlägt, selbst nach dem letzten Commit von (ghes) Fix von @mcaulifn

DEBUG   https://enterprise.github.custom.com/api/v3

ERROR   RequestError [HttpError]: request to https://enterprise.github.custom.com/api/v3/app/installations/22/access_tokens 
failed, reason: connect ETIMEDOUT 192.168.1.1:443
    at /var/task/index.js:2797:11
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async getInstallationAuthentication (/var/task/index.js:266:7) {
  status: 500,
  headers: {},
  request: {
    method: 'POST',
    url: 'https://enterprise.github.custom.com/api/v3/app/installations/22/access_tokens',
    headers: {
      accept: 'application/vnd.github.antiope-preview+json,application/vnd.github.machine-man-preview+json',
      'user-agent': 'octokit-request.js/5.4.12 Node.js/12.19.0 (linux; x64)',
      authorization: 'bearer [REDACTED]',
      'content-length': 0
    }
  }
}

ERROR RequestError [HttpError]: request to https://enterprise.github.custom.com/api/v3/app/installations/22/access_tokens failed, 
reason: connect ETIMEDOUT 192.168.1.1:443 at /var/task/index.js:2797:11 at processTicksAndRejections 
(internal/process/task_queues.js:97:5) at async getInstallationAuthentication (/var/task/index.js:266:7) 
{ status: 500, headers: {}, request: { 
    method: 'POST', url: 'https://enterprise.github.custom.com/api/v3/app/installations/22/access_tokens', 
    headers: { accept: 'application/vnd.github.antiope-preview+json,application/vnd.github.machine-man-preview+json', 
    'user-agent': 'octokit-request.js/5.4.12 Node.js/12.19.0 (linux; x64)', authorization: 'bearer [REDACTED]', 
    'content-length': 0 } } }



ERROR   Invoke Error    
{
    "errorType": "Error",
    "errorMessage": "Failed handling SQS event",
    "stack": [
        "Error: Failed handling SQS event",
        "    at _homogeneousError (/var/runtime/CallbackContext.js:12:12)",
        "    at postError (/var/runtime/CallbackContext.js:29:54)",
        "    at callback (/var/runtime/CallbackContext.js:41:7)",
        "    at /var/runtime/CallbackContext.js:104:16",
        "    at /var/task/index.js:50911:16",
        "    at Generator.throw (<anonymous>)",
        "    at rejected (/var/task/index.js:50893:65)",
        "    at processTicksAndRejections (internal/process/task_queues.js:97:5)"
    ]
}

@buamod verwendest du GHES? Rechts? Nur um sicher zu gehen, haben Sie das Lambda neu aufgebaut und sichergestellt, dass es verwendet wird?

ETIMEDOUT würde vorschlagen, dass GHES nicht reagiert hat. Stehen Sie hinter einem Proxy?

@buamod verwendest du GHES? Rechts? Nur um sicher zu gehen, haben Sie das Lambda neu aufgebaut und sichergestellt, dass es verwendet wird?

Ich habe die neuesten Commit-Lambdas bereitgestellt, ich habe sie mit Docker-Befehlen aus dem Skript Ci/build.sh erstellt.

ETIMEDOUT würde vorschlagen, dass GHES nicht reagiert hat. Stehen Sie hinter einem Proxy?

Es könnte einen Proxy geben, den ich nicht kenne. Nehmen wir an, es gibt einen Proxy, wie würde ich das übergeben?

@buamod- Proxy-Anforderungen können stark abweichen. Ich würde vorschlagen, dass Sie sich an Ihr Netzwerkteam wenden, um zu erfahren, was sie benötigen, um die Verbindung zu bestehen.