-
Notifications
You must be signed in to change notification settings - Fork 95
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
Create reference.zip file during build process #213
Comments
@SableRaf I just updated the issue description to reflect the current state of the research for this. I can try to prioritize this in the coming weeks. |
That's fantastic @runemadsen! Thanks a lot for looking into this. Pinging @benfry for the PDE side. |
I've been thinking some more about this and here's what I think needs to change. We have a kind of "chicken or the egg" problem here because we trigger the website builds by manually creating releases, so if the release needs the have the ZIP file, we need to update the release with the ZIP file once the build ends. If we keep this flow, it will look something like this:
The result of this is that any release will have a 10-15 minute delay before it has a ZIP file attached. Instead, I'm thinking that it would be preferred if we flipped the logic around, so we start manually triggering the GitHub action via the UI which then will build and upload the website and then create a release with a ZIP file attached. This flow will look something like this:
@SableRaf @benfry What do you think about this? If you think it's a good approach, we can get going on it. |
Hi @runemadsen thanks for the update. So just to make sure I understand: in your suggested approach, we wouldn't have to manually create a new release but instead just run a Github action that builds/uploads the website, then zips it and creates the release? |
Yes, it will basically be the same thing, but you will have to press "Run Action" instead of creating a release. We could use the |
Yeah the release number isn't used for anything meaningful. Would there be a way to add a description for the release when needed? |
I was just looking at this, and we can use input parameters for the GitHub action to allow you to specify a version and description when running the action in the GitHub interface. |
Update on this: I pretty much have everything ready to go, and I just need to take some time to test it on the live repo. The problem is that manually triggered actions only work on @SableRaf Is this okay with you? |
Yes that sounds good! Thanks for asking @runemadsen. I just made a release to get the latest changes out of the way so you're all clear for testing the new GitHub action. Make sure to label those releases as tests. |
Great, will do! |
@SableRaf @benfry This has been implemented! You'll see that I made a test release that has the I vote for closing this issue and opening a new one linked to this one named "Minimize size of reference.zip file" so we can track the needs in a separate issue. |
Great! That's a huge improvement. Thanks @runemadsen ✨
That sounds good. Do you want to go ahead and create the new issue or should I open one? |
Great! I can create the issue now. |
We need to create a
reference.zip
file during the build process that the Processing IDE can download when needed. This issue actually covers two main things:reference.zip
file during buildMinimize the size of thereference.zip
fileAs far as minimizing the size of the
reference.zip
file, I have done some research to figure out next steps, and some work has already been done to fix some things. However, there are plenty of more short-term and long-term work to do.As a quick explanation of the current bundle size: Gatsby prioritizes speed and size of loaded content over bundle size, which is great for serving over the web, but not so great if the size of the stored content matters. One example of this is that the same page content is saved in the HTML files and page-data JS files, but only one of those files will be loaded by the user depending on whether it's the initial load (HTML) or link navigation (page-data). But both are obviously contributing to the bundle size, even though some of this is de-duplicated by the zipping algorithm. On top of this comes things like responsive images, which produces 3-4 versions of each image in the final bundle, but works in the same way: Only a single image is loaded, but all of them are in the bundle. So in some way, we're going to need to fight Gatsby a bit to get the best of both worlds.
Here are some short-term things we can do:
I did a quick test of these things:
We might find more when we start working through these things, but the 50-60MB ZIP file seems very doable. We also need to localize some things, like not relying on the P5.js CDN version, but that's trivial. The longer term work will be going through the code with this constraint in mind and template by template looking at the file sizes and what optimizations can be done. This can save a lot of space based on the way Gatsby works, but I'm not sure how much and it'll take a bit more time.
The text was updated successfully, but these errors were encountered: