cloud icon indicating copy to clipboard operation
cloud copied to clipboard

Deploy Logs

Open Gazzini opened this issue 2 years ago • 4 comments

Here's a pickle... I'm working on this project: https://github.com/Gazzini/crm

I can run cloud, and the app deploys to my personal instance, and it works great. This takes less than 30 seconds.

However, if I run cloud deploy production, the deploy hangs forever.

Is there any way for me to inspect what's going on?

Gazzini avatar Feb 05 '22 00:02 Gazzini

Sorry about this. You're right that we should be surfacing more logs to your client, I'll add an issue to our backlog to improve that.

In your immediate case, as far as I can tell this is due to the size of your node_modules folder, which is almost 500MB. By default, cloud syncs everything - we're working on ways we can make this better, but we want to have your devDependencies available to us because eventually we want to be able to run things like dev servers in your personal sandbox to better support frontend frameworks. What's happening is it's timing out bundling everything to deploy (personal sandboxes work a bit different)

For now we support a .serverlessignore file that takes glob patterns to exclude, however, I took a stab at trying to omit things that were not needed but it seems like Prisma is problematic, it's just huge - I tried to follow the advice I found from Prisma about deploying to Lambda, and I applied it in a PR here: https://github.com/Gazzini/crm/pull/3

I was able to start a personal sandbox, as well as do a deployment to a stage - I know this isn't ideal and is clunky, we will make it better. I'm not sure if this actually works since it blows up looking for a database and whatnot.

dougmoscrop avatar Feb 05 '22 04:02 dougmoscrop

Oh, and we are actively working on improving cold start times, but I wanted to point out that Prisma seems to have a couple issues still open https://github.com/prisma/prisma/issues/10724 https://github.com/prisma/prisma/issues/11266 -- just FYI.

dougmoscrop avatar Feb 05 '22 04:02 dougmoscrop

Awesome, thanks for the context!

I didn't realize my node_modules folder was so big -- I was able to shrink it from 454M -> 304M by excluding the dev dependencies with npm install --production, but I'm still pretty far off, according to the new error message I'm seeing:

Unzipped size must be smaller than 167106156 bytes (~167 mb).

It's actually great to see that message 🎉 , I wasn't seeing it before.

I'll play around with .serverlessignore and see what I can live without... but it doesn't look good for the marriage of Prisma & Serverless Cloud 😅 .

fwiw... I can see how it's tough to tree-shake the node_modules folder on the backend (people sometimes do unusual imports), but I'd guess that you'll hit more pain from node_modules size than you will from whacky importers. Of course, there's clearly a lot I'm not considering ("dev servers in sandbox" etc...).

Right now, you:

  • don't tree-shake
  • have an exclude-list (.serverlessignore)

I guess it's actually a little bit more gross to:

  • always tree-shake (or, at least on stages)
  • have an include-list (.serverlessAlwaysIncludeEvenIfNobodySeemsToImportIt) lol

Gazzini avatar Feb 05 '22 10:02 Gazzini

I still have a few ideas, but the intention is to make serverlessignore a last resort - for example, with prisma, we may just build in ignoring the bits that aren't needed, or, move to containers for deployment if your bundle size is larger than the limit - the goal will always be for us to manage as much of the complexity as possible without getting in your way.

Again, sorry for the inconvenience, but please let me know if anything else that comes up. There's a lot to do so user feedback helps with prioritizing!

dougmoscrop avatar Feb 05 '22 15:02 dougmoscrop