Terraform-aws-github-runner: Échec de la mise à l'échelle de lambda

J'ai eu la même erreur, essayez de donner les droits d'application sur le groupe Actions.

@adrianmiron L' avez-vous corrigé ?

même problème +1

@npalm Pourriez-vous

@adrianmiron j'ai essayé le groupe Actions mais j'ai toujours un problème. Pouvez-vous partager toutes vos autorisations ? J'essaie le coureur d'organisation.

Je ne reconnais pas le problème La mise à l'échelle lambda récupère un message dans la file d'attente, puis vérifie s'il y a toujours des travaux en file d'attente. Si oui, il s'agrandit. La mise à l'échelle lambda est déclenchée pour les messages qui sont pendant 30 secondes dans la file d'attente. Le message d'erreur indique que le lambda n'est pas autorisé à appeler l'API.

Pouvez-vous vérifier si votre application GitHub est configurée conformément à la documentation. Étant donné que votre lambda de mise à l'échelle est déclenchée, il semble que l'application soit installée pour le référentiel, sinon aucun événement ne devrait être reçu. Donc, la plupart des apparences légales semblent que les autorisations ne sont pas correctement définies.

@manoj-k-deepr D'après mes enquêtes sur la même erreur, il s'est avéré qu'il s'agissait de problèmes d'autorisation de l'application github (qui est celle qui effectue réellement la requête sur les actions de dépôt. Je me souviens que j'ai parcouru l'application lambda -> github chose 5 fois et ce n'était pas ça.

Partagez un printscreen avec des autorisations sur organisation/repo et je comparerai dans la matinée.

@npalm oui son problème avec autorisation. J'ai résolu le problème en fournissant un accès aux coureurs auto-hébergés ( lecture et écriture ) dans l'organisation. Dans la documentation, rien n'est mentionné sur l'autorisation du coureur.

Il y a eu un problème avec les autorisations de l'application Github. @npalm Pouvez-vous mettre à jour la documentation et spécifier quelle demande d'autorisation nécessite

@mkryva Super, vous l'avez fait fonctionner. Je vais laisser le problème ouvert afin que nous puissions mettre à jour les documents. Les relations publiques pour l'amélioration des documents sont toujours les bienvenues !

Après la mise à jour des autorisations, cela échoue avec l'erreur suivante :

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

UPD : On dirait que la raison était « Vous avez atteint votre quota de demandes de flottes ponctuelles maximales pour ce compte ».

augmenter lambda échoue pour moi, même après le dernier commit de (ghes) correctif par @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 vous utilisez GHES ? Droit? Juste pour être sûr, avez-vous reconstruit le lambda et vous êtes-vous assuré qu'il est utilisé ?

ETIMEDOUT suggérerait que GHES n'a pas répondu. Êtes-vous derrière un proxy?

@buamod vous utilisez GHES ? Droit? Juste pour être sûr, avez-vous reconstruit le lambda et vous êtes-vous assuré qu'il est utilisé ?

J'ai déployé les derniers lambdas de commit, je les ai construits avec les commandes docker du script Ci/build.sh.

ETIMEDOUT suggérerait que GHES n'a pas répondu. Êtes-vous derrière un proxy?

Il y a peut-être un proxy que je ne connais pas. Disons qu'il y a un proxy, comment pourrais-je passer ça ?

Les exigences du proxy