Terraform-aws-github-runner: Échec dev-usw2-scale-up : « Echec de la gestion de l'événement SQS » « routines PEM :get_name :no start line at Sign.sign »

J'ai vu exactement le même problème si vous avez effectué un encodage base64 de la clé PEM SANS le
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

Il semble que vous deviez prendre le contenu complet du fichier .pem et l'encoder en base64.

Merci @compiaffe ! c'était certainement un problème.

Il serait certainement utile d'avoir quelque chose comme ceci dans le README/docs :

• GITHUB_KEY=$(base64 ./myapp-aws-github-runner.2020-07-29.private-key.pem) ; cat $GITHUB_KEY > encoded_key.out now use this entire file as the github_app_key_base64 value

J'ai redéployé et je vois maintenant l'erreur SQS suivante dans la fonction de mise à l'échelle lambda, "curieux si vous avez déjà vu celle-ci?

2020-07-29T12:38:43.476-07:00 | 2020-07-29T19:38:43.476Z    e67a6201-6e39-50c8-94f7-359abc4954cd    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:17333:16",         "    at Generator.throw (<anonymous>)",         "    at rejected (/var/task/index.js:17315:65)",         "    at processTicksAndRejections (internal/process/task_queues.js:97:5)"     ] }

Merci.

@ cmcconnell1 oui j'en ai vu un. Vérifiez l'entrée de journal avant, elle affichera probablement un appel d'API vers un point de terminaison Github auquel 403.

J'ai dû donner à l'application Github les autorisations pour les actions, les vérifications et les coureurs auto-hébergés, mais je ne semble pas avoir besoin de lui donner accès à l'administration.

N'oubliez pas d'aller dans l'installation sur l'organisation ou le référentiel et autorisez la demande d'autorisations plus/différentes.

Merci @compiaffe . Il semble que des autorisations supplémentaires soient requises qui ne sont pas spécifiées dans le fichier README.
Je n'ai maintenant plus d'erreurs dans les journaux lambda/cloudwatch, et je vois le fichier action-runners.zip dans le compartiment S3, et je suis capable de suivre le README et de voir la fonctionnalité attendue _sauf_ la création d'instance spot--cela semble être mon dernier problème.

ref: scaling-selfhosted-action-runners#putting-all-together

Si vous construisez, les coureurs ne démarrent pas ou ne s'inscrivent pas. Le mieux que vous puissiez faire est de suivre la trace. Dans l'application GitHub, il y a une page de paramètres avancés où vous pouvez voir les événements envoyés au webhook. Lorsque l'événement n'est pas accepté, vérifiez le point de terminaison et le secret. Ensuite, vous pouvez vérifier les journaux du webhook et mettre à l'échelle lambda dans Cloud Watch. Enfin, vous pouvez inspecter l'enregistrement des données utilisateur EC2. L'accès via SSM (MP : devrait-il s'agir de ssh ?) est activé par défaut. Il suffit de sélectionner se connecter à l'instance et d'inspecter le journal /var/log/user_data.log.

Le point d'erreur se situe après lambda et cloudwatch, et la prochaine étape de dépannage consiste à inspecter les données utilisateur EC2 (journaux), mais c'est un peu difficile car je n'ai pas d'instance lorsque les instances ponctuelles ne se déploient pas.

Merci pour votre aide.

Toujours confronté à un problème ?

@npalm nous avons dépassé cela, il me manquait le début / la fin du certificat. Cependant, nous sommes toujours bloqués avec la balise v0.2.0 sans déploiement des instances ponctuelles et aucune indication dans les journaux d'erreurs pour indiquer un échec/un problème. AIR, l'effet net était le même que dans https://github.com/philips-labs/terraform-aws-github-runner/issues/104 bien que nous ne voyions aucune erreur d'autorisation. J'ai été en vacances et je vois maintenant qu'il existe une version de balise 0.3.0 et 0.4.0 avec laquelle je vais commencer à tester. Merci.

J'ai le même problème, j'ai utilisé la branche develop/0.0.5, j'ai également effectué un encodage base64 (y compris les bits BEGIN et END) et j'ai enregistré la valeur dans le fichier variables.tf comme ci-dessous, mais j'obtiens toujours l' erreur : . (Erreur : erreur : 0909006C : routines PEM