Got an our of memory error is a post deploy phase ...
# seed
o
Got an our of memory error is a post deploy phase running tests - any way to bump it up?
$ cd tests/api-tests && echo “Running API tests” && yarn start
104.89 s
Running API tests
yarn run v1.22.10
$ cd ./../ && yarn test tests/api-tests
$ serverless-bundle test tests/api-tests
FAIL tests/api-tests/tests/new_ledger.createOrder.test.ts
● Test suite failed to run
jest: failed to cache transform results in: /tmp/jest_0/jest-transform-cache-ba6890a420e1a6b5180fa098b09849d2-d1d5bfaad8659acd06069518d3e76e6c/7b/PossibleFragmentSpreadsRule_7b3725f55fe601a32ee8cced42acf655.map
Failure message: ENOMEM: not enough memory, write
at writeFileSync (node_modules/@jest/transform/node_modules/write-file-atomic/index.js21510)
at writeCacheFile (node_modules/@jest/transform/build/ScriptTransformer.js79233)
at ScriptTransformer.transformSource (node_modules/@jest/transform/build/ScriptTransformer.js5377)
at ScriptTransformer._transformAndBuildScript (node_modules/@jest/transform/build/ScriptTransformer.js56940)
at ScriptTransformer.transform (node_modules/@jest/transform/build/ScriptTransformer.js60725)
FAIL tests/api-tests/tests/existing_ledger.addLedgerEntry.test.ts
p
Click on the service that failed to edit it's setting and change the build machine entry to Medium SG or High SG. I'd try Medium first and only bump it up to High if that fails too
o
This is in post deploy phase, not a service, so no options to select a machine
p
Ah... The post deploy would run inside a lambda, so you'd have to bump that up right?
o
Not sure how it runs, but in SEED the only options are the command to run
p
I think I was getting mixed up with the Script construct that you set to run on deployment - sorry!
o
Might not be a bad idea to move over to that tbh - but playing around with switching to running these tests using esbuild-jest
p
Basically the bit about "Post-Deploy phase vs after_deploy hook"
o
Yeah these tests are for the entire system - it calls the API, then makes sure that the entire system is working, including async stuff off queues
p
I'm pretty sure you get a lambda created for the after_deploy hook, so I expect you get one for the post-deploy phase too. Not sure if you can configure it via SST - you'd have to have a dig through the SST and maybe CDK docs. You could try configuring it via the AWS site to see if bumping up the memory helps. The default seems to be 1024MB
o
I thought that after_deploy runs on the same box that just deployed the service
post deploy phase I think runs on the same infra, but gets its own “box”, which doesn’t seem configurable
p
We have an after_deploy script and I can see a function listed in lambda for it
In fact, we have post deployment scripts for create, update and delete - there's items listed for all three
o
that’s using the SST Script construct? or from SEED?
p
SST Script
The docs make them sound like they're done in similar ways
The lambdas for the SST Scripts are set to 2048MB by default - FYI
If you have a dig around in lambda on the AWS site, you'll likely find a lambda function that matches the post phase - possibly even an application too
o
Umm I think SEED builds are run on something closer to containers not lambda, but I’ll go take a look
p
You could well be right, it's how the other stuff runs, but I wouldn't be surprised if it was done differently. It would explain why you don't get the same options.
f
Hey @Omi Chowdhury, Post-Deploy phase currently inherits the machine size from the first service in your pipeline.
In the example below, Post-Deploy phase inherits the machine size from
posts
Can you try changing the size of the first service?
^^ We will be letting you specify machine size for the Post-Deploy phase directly.
p
I guess my guess wrong! Thanks for the clarification (as always) @Frank
o
Resolved this issue by switching to esbuild 🙂