Replies: 2 comments 1 reply
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
The issue could be resolved, it is was in fact really For V3 the configuration for We have now moved the settings to the correct keys and adapted them where new names had to be applied. So in fact this is not a Github Actions issue at all but rather a bug and oversight on our end. What lead us to believe it had something to do with Github Actions is, that this issue showed up slowly over time. Alreay weeks back we had failed/cancelled builds every now and then but did not think much of it but rather thought perhaps some platform rescaling that hits us. But after a larger migration the issue showed up consistently. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Why are you starting this discussion?
Question
What GitHub Actions topic or product is this about?
Actions Runner
Discussion Details
We have an application which built (and deployed) just fine from Github Actions. The application is a Serverless API built in TypeScript. It was built from around 20 Serverless microservices and due to a migration we are running right now, we could reduce these microservices down to only 4 service files that we still need to deploy.
What we basically did is we refactored our API to run off of a single
serverless.ymlfile, with a "Lambdalith" model. Where basically a proxy Lambda routes traffic to our business logic. After refactoring we ended up with the following service files (serverless.yml).ressources: Just CloudFormation resources that form the infrastructure of the application (deploys fine)proxy-api: The Lambdalith proxy (deploys fine)attachments-api: Reacts to some S3 events to generate previews of office and PDF documents (deploys fine)cron-api: Holds a collection of cron jobs (fails deployment)We have strong indication that we violate some resource limit of the Actions Runner as the runs jump into state "Cancelled" but are not cancelled by us. Also in the logs we have seen the Signal 137, which indicates the same.
And the final indicator that it has something to do with the Actions Runner is that the same build and deployment runs just fine from local developer machines, with the exact same versions of Serverless, NodeJS and TypeScript.
The error we get from Serverless indicates that the build was stopped / cancelled during
esbuild- in the transpiling phase:Is there a way to get detailed logging for a runner to see why it cancelled the run?
Beta Was this translation helpful? Give feedback.
All reactions