スケールアップラムダは、出力に異常がない状態でその呼び出しをCloudwatchに記録しますが、少なくとも明らかにエラーであるものはありませんが、新しいインスタンスは作成されず、ジョブはキューに入れられたままになります。 エラーがないため、次にどこを見ればよいかについて少し行き詰まっています。
START RequestId: b6d27abc-24a7-5f67-a7a9-220b3a8f2e0a Version: $LATEST
--
{
Records: [
{
messageId: 'c5118c89-b1db-4a81-9fd1-c3211020f447',
receiptHandle: 'AQEBVpllIHtC29mzlvsdPt7y3HfIZHfGThi4dwb2ecHzqupGCRBtFBVFWNa9KKd7M3VwcyiVf6/uqKh/czW305hG9gkqvsnnDj1sdUIqXdzky6+z8ZJnylM/ekUA1bmv7bJna0K5Gbkr+2p1o5UcRoaZnr1EfijnlxabX2ft2JyxNvhVEjVJGEhJMOwIJmXnzlelKAqGh0gz+jde1hecenob2hS9aKEf+8pk6kJViSC0jZvb9S1hcBfHoNTsmP5z45+WzeyTeFDmcO3QmAeIsl4cj4fCwimpQvV1OyE8oBZ5QjE=',
body: '{ "id": 2005872726, "repositoryName": "redacted", "repositoryOwner": "redacted", "eventType": "check_run", "installationId": 15044875 }',
attributes: {
ApproximateReceiveCount: '1',
SentTimestamp: '1614617562674',
SequenceNumber: '18860086169754095872',
MessageGroupId: '2005872726',
SenderId: 'AROAYDZX6OHXHIADI55JV:gh-ci-webhook',
MessageDeduplicationId: '47a99738074ab0818b7881eee096ec21a5b82226764304d9ab69d90ff39ea349',
ApproximateFirstReceiveTimestamp: '1614617592695'
},
messageAttributes: {},
md5OfBody: 'd5e6cdc10ecd1a37128c56a1ed6bb90f',
eventSource: 'aws:sqs',
eventSourceARN: 'arn:aws:sqs:eu-west-1:redacted:gh-ci-queued-builds.fifo',
awsRegion: 'eu-west-1'
}
]
}
誰かアイデアはありますか?
私の側でも同じことがわかり、GitHubアクションの最近のパフォーマンス低下インシデントに関連しているのではないかと疑っています。
リポジトリでキューに入れられたワークフローのリストをフィルタリングしようとすると、次のエラーが発生し、キューに入れられたワークフローが明らかに存在する場合は空のリストが表示されます。
We are having problems searching workflow runs. The results may not be complete.
ラムダはこれに依存して、キューに入れられたワークフローを返し、インスタンスを起動すると思います。
まったく同じことを見てください。
手動でスケールアップを強制する簡単な方法があるかどうかを調べようとしていました。 アイドル設定はスケールダウン中にのみチェックされるようですか? 私はコードに慣れていないので、何かを見逃している可能性があります。
同様の問題に少し時間を費やしましたが、ポリシーによってEC2に必要なタグが原因で、EC2が失敗していることがわかりました。 CloudTrailAPIエラーを調べることでそれを見つけることができました。
みなさん、これまでの回答ありがとうございます。
@rlove Cloudtrailで、スケールアップラムダがエラーまたはその他の方法で何かを実行していることを示唆するものが見つかりません。
@samgilesはい、これも私が調べていたものでした。 スケールアップラムダを強制的に実行するテストイベントを(限られた時間内に)作成できませんでした。
@ eky5006それは理にかなっていますが、それでも同じ問題が発生しており、 https: //www.githubstatus.com/incidents/xn0sd2x4nd7fによると問題は解決しています。 あなたはあなたの終わりに何か良く見えていますか?
私も同じ問題を抱えてる。
キューに入れられたジョブがある場合でも、 INFO Repo < repo name > has 0 queued workflow runs
。 そして、このAPI https://docs.github.com/en/rest/reference/actions#list -workflow-runs-for-a-repositoryは、キューに入れられたワークフローを適切に返します。
それは昨日起こり始めましたが、それでも機能しません。
INFO Repo < repo name > has 0 queued workflow runs
@bartoszjedrzejewskiその出力はどこに表示されますか?
@rjcoupeは、cloudwatchログをスケールアップします。 どのバージョンを使用していますか? 0.8.1を使用しているからだと思います。 今更新しようとしています。 私の同僚はこの問題を抱えていません、彼は0.10にいます
私は同じ問題を抱えていました、停止は何人かの長引く登録されたランナーを残しました。 GitHub組織から登録を解除しましたが、ランナーは期待どおりにスケールアップしています。
これが誰かに役立つことを願っています。
ラムダを0.8.1から0.11.0に更新すると、問題が修正されました。
こんにちは、昨日同じ問題が発生し、ラムダを0.8.1から0.10.0にアップグレードしても問題は解決しました。
私はv0.10.0を使用していたので、あまり期待できませんでしたが、v0.11.0で問題が解決したようです。 奇妙な!
@gertjanmaasどんな考えでも、昨日の停止に関連しているように見えます。
昨日の停止に関連している可能性があります。 この場合、特定のリポジトリがWebhookにイベントを送信しなかったため、ジョブがキューに入れられ、インスタンスが作成されませんでしたが、使用するAPIのいずれかに影響を与えた可能性があります。
停止が修正されたため、それが原因である場合は、これを解決する必要があります。
いいえ、AWSリソースに変更を加えずに、今朝から再び発生しています。 正しい振る舞いはまぐれだったようです。
ダイナミックなセルフホストランナーだけでなく、今日のすべてのアクションで問題が何度も発生していることを知りました。 GitHubで安定性の問題が発生していると思います。
最も参考になるコメント
私はv0.10.0を使用していたので、あまり期待できませんでしたが、v0.11.0で問題が解決したようです。 奇妙な!