How does this compare to Gatsby incremental builds?

[Vacilando]

Hi, how does this plugin compare to Gatsby's new incremental builds? See https://www.gatsbyjs.org/blog/2020-04-22-announcing-incremental-builds/

Are they trying to achieve the same and are exclusive of each other, or do they complement each other?

[jlengstorf]

this is a part of incremental builds

your timing is perfect, actually, because I just wrote a post showing how to enable Gatsby incremental builds on Netlify!

this plugin keeps the public and .cache folders around between builds, which Gatsby uses for incremental builds. there's also a flag that needs to be set and a minimum version of Gatsby required (I cover all that in the post), but all-in it takes 5 steps to implement and test it

I'm going to close this, but feel free to follow up with any questions!

[polarathene]

this is a part of incremental builds

Is there a breakdown of what is required to achieve this functionality in a self-hosted manner?

So far I'm only aware of:

• This caching step (which I thought was a common optimization with CI services? I've done such with Travis for example).
• Distributed builds via a job-scheduler/work-queue as described here with gatsby-parallel-runner on GCP. Not specifically incremental, but can reduce build time.

Is there anything else going on, or by using this plugin and following your netlify article, you'd have the equivalent incremental build functionality Gatsby Cloud offers?

---

EDIT: Missed the netlify article linked in your response here, whoops!

It seems this was only about the caching. The distributed jobs part of the builds is the only other feature according to this Jan 2020 blogpost about Gatsby Builds

The May 2020 blog post introducing willit.build mentions at the end three types of builds, with the build triggered by CMS content change only being available via Gatsby Cloud. Presumably, that involves the build being triggered to notice if the repo has received no new commits, and thus somehow informs Gatsby during build to only check for CMS content?

Is this via some internal plugin instead of passing a flag to gatsby build to optimize for that, or is it related to the CMS integration/support Gatsby Cloud offers, where it's perhaps being informed of the specific change(s) or some other feature not available to the general public(or requiring some intermediary layer/plugin)?

---

Gone through another article, this time April 2020, about incremental builds, it seems to imply the assumption that there might be some CMS feature used with providers that is either private or varies and Gatsby Cloud normalizes the different APIs for the feature to work well:

In order to build incrementally, we need tight integration with the CMS to be able to detect changes. To get to the build speeds we’re after, it’s not fast enough to fetch all recent data and figure out what’s changed; we need to integrate at a lower level with the CMS, and every CMS is different.

[jlengstorf]

@polarathene Gatsby hasn't really explained what happens (which makes sense, since they're positioning it as their product/competitive advantage and not part of the open source tool), so it's hard to do anything other than speculate right now

for any concrete breakdown, the Gatsby team would need to comment