Terraform-aws-github-runner: Scale Up lambda 报告没有错误,但没有启动新的跑步者

创建于 2021-03-01  ·  15评论  ·  资料来源: philips-labs/terraform-aws-github-runner

放大的 lambda 将其调用记录到 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'
}
]
}

谁有想法?

最有用的评论

我在 v0.10.0 上,所以没有抱太大希望,但 v0.11.0 似乎确实解决了这个问题。 奇怪!

所有15条评论

我看到了同样的结果,我怀疑这与最近 GitHub 操作的性能下降事件有关。

当尝试过滤我们的 repo 上的排队工作流列表时,我们得到以下错误和一个空列表,当显然有排队工作流时:
We are having problems searching workflow runs. The results may not be complete.

我认为 lambda 依赖于它来返回排队的工作流来启动一个实例。

看到完全一样的东西。

我试图弄清楚是否有一种简单的方法可以手动强制放大。 似乎空闲配置仅在缩减期间检查? 我对代码不熟悉,所以可能错过了一些东西。

我花了一些时间在类似的问题上,我发现我的 EC2 by Policy 所需的标签导致它失败。 我可以通过查看 CloudTrail API 错误找到它。

感谢大家迄今为止的回复。

@rlove我在 Cloudtrail 中找不到任何东西表明 scaleup lambda 正在做任何事情,无论是错误还是其他。
@samgiles是的,这也是我正在研究的东西; 我不能(在有限的时间内,诚然)设计一个测试事件来迫使 scaleup lambda 付诸行动。
@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 组织中取消了它们的注册,现在跑步者正在按预期扩大规模。

希望这可以帮助某人。

将 lambdas 从 0.8.1 更新到 0.11.0 解决了我的问题。

嗨,我们昨天遇到了同样的问题,将 lambdas 从 0.8.1 升级到 0.10.0 也解决了这个问题。

我在 v0.10.0 上,所以没有抱太大希望,但 v0.11.0 似乎确实解决了这个问题。 奇怪!

@gertjanmaas任何想法,看起来与昨天的停电有关。

可能与昨天的停电有关。 在我们的例子中,某些存储库没有向 webhook 发送事件,这导致作业排队并且没有创建实例,但它可能会影响我们使用的任何 API。

中断已经修复,所以如果这是原因,应该解决。

不,今天早上又发生了,AWS 资源没有任何变化。 似乎正确的行为是侥幸。

刚刚了解到,我们今天的所有操作都时断时续地看到了问题,而不仅仅是动态的自托管运行器。 我认为 GitHub 上存在稳定性问题。

此页面是否有帮助?
0 / 5 - 0 等级