Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large build output cannot be uploaded #32

Closed
asquithea opened this issue Jun 27, 2022 · 7 comments · Fixed by #67
Closed

Large build output cannot be uploaded #32

asquithea opened this issue Jun 27, 2022 · 7 comments · Fixed by #67
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@asquithea
Copy link

asquithea commented Jun 27, 2022

I found that artifacts from the end of my build pipeline (just before deploy) are not cached.
Bit of a show-stopper as it causes a full redeploy!

It looks like Fastify has a default body size limit of 1 MiB, and so I'm speculating this is the reason.

Could we have a configuration option to bump this considerably higher?

A backport to the last stable version (so 1.1.2 I guess) would be really helpful, BTW.

@fox1t
Copy link
Contributor

fox1t commented Jun 28, 2022

This is strange. We already have the limit increased from default here: https://github.com/fox1t/turborepo-remote-cache/blob/main/src/plugins/remote-cache/index.ts#L18

@asquithea
Copy link
Author

asquithea commented Jun 28, 2022

Hmm. I'm building individually packaged lambda functions using esbuild, so the packages are varying between about 1 MB and 5 MB. But there are quite a lot of them in one service... the total size of the service build folder containing the ZIP files is 228 MB! This probably explains it if they're all being uploaded together as a single artifact: no reason to think your limit is ineffective.

100 MB does seem like a reasonable limit if the data is being buffered in memory. Do you think it would be possible to stream the request to storage? Along the lines of fastify/fastify#534 ? I appreciate this is probably harder to implement, though it might yield a performance benefit.

@asquithea asquithea changed the title Artifacts over 1? MiB cannot be uploaded Large build output cannot be uploaded Jun 28, 2022
@fox1t
Copy link
Contributor

fox1t commented Jun 29, 2022

I think we can support arbitrary significant artifacts using a strategy similar to one I used here: https://github.com/fox1t/fastify-multer (multer is only for form-data/multipart).

The idea is to have a content parser that flags the incoming request as "interesting" and then handles the upload in a preHanlder function, piping the incoming stream directly to a writable stream (regardless of the local file or remote bucket).

Would you like to open a PR to support it?

@matteovivona matteovivona added the wontfix This will not be worked on label Jul 11, 2022
@fox1t fox1t added enhancement New feature or request help wanted Extra attention is needed and removed wontfix This will not be worked on labels Jul 12, 2022
@tm1000
Copy link
Contributor

tm1000 commented Oct 27, 2022

This might also be related to vercel/turborepo#2096 and vercel/turborepo#2280

@tm1000
Copy link
Contributor

tm1000 commented Oct 27, 2022

After further testing and creating a PR in turborepo (vercel/turborepo#2428)

I can confirm that I was able to upload an artifact of 92mb to the ducktors/turborepo-remote-cache server implementation. It took about 1min

@simonjpartridge
Copy link

I have an issue where my artifacts are larger than the 104mb file size limit.

Would it be possible to increase the default, or add an environment variable to set this limit for the server?

@tm1000
Copy link
Contributor

tm1000 commented Oct 31, 2022

I'd like the same as @simonjpartridge. An environment variable would be great

tm1000 added a commit to tm1000/turborepo-remote-cache that referenced this issue Nov 2, 2022
@tm1000 tm1000 mentioned this issue Nov 2, 2022
@fox1t fox1t closed this as completed in #67 Nov 5, 2022
fox1t added a commit that referenced this issue Nov 5, 2022
matteovivona pushed a commit that referenced this issue Nov 5, 2022
## [1.7.3](v1.7.2...v1.7.3) (2022-11-05)

### Bug Fixes

* [#32](#32), [#62](#62) ([1052cb7](1052cb7))
* remove mapped envs ([ea614b3](ea614b3))
* typescript ([2f2902e](2f2902e))
* update dockerfile ([e03a900](e03a900))
TryEverything920609 pushed a commit to TryEverything920609/turborepo-remote-cache that referenced this issue Aug 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants