Gatsby: Gatsby build on Netlify fails(Image generation): Command did not finish within the time limit

Created on 11 Sep 2018 · 59Comments · Source: gatsbyjs/gatsby

Description

The build on Netlify fails with error: Command did not finish within the time limit.
When I run a local build the build is much faster.

Steps to reproduce

Running gatsby build on Netlify

Expected result

The build should succeed in a reasonable amount of time, just like when running the build locally:

Build log:

success open and validate gatsby-config — 0.010 s
success load plugins — 0.172 s
success onPreInit — 0.469 s
success delete html and css files from previous builds — 0.005 s
success initialize cache — 0.007 s
success copy gatsby files — 0.039 s
success onPreBootstrap — 0.004 s
⠁ Starting to fetch data from Prismic
⠈ source and transform nodesFetch Prismic data: 933.771ms
success source and transform nodes — 12.536 s
success building schema — 0.997 s
success createPages — 0.170 s
success createPagesStatefully — 0.149 s
success onPreExtractQueries — 0.004 s
success update schema — 0.830 s
success extract queries from components — 0.294 s
success run graphql queries — 19.262 s — 199/199 10.33 queries/second
success write out page data — 0.007 s
success write out redirect data — 0.001 s
Generating image thumbnails [==============================] 1690/1690 367.4 secs 100%

info bootstrap finished - 389.838 s

success onPostBootstrap — 0.011 s
success Building production JavaScript and CSS bundles — 7.609 s
success Building static HTML for pages — 1.887 s — 198/198 265.21 pages/second
info Done building in 399.357 sec

Actual result

The build fails: Command did not finish within the time limit.

Build log:

4:15:29 PM: Build ready to start
4:15:31 PM: build-image version: 42bca793ccd33055023c56c4ca8510463a56d317
4:15:31 PM: buildbot version: 6bab8b64bbd90091082af19fedf16bf73d502e5e
4:15:31 PM: Fetching cached dependencies
4:15:31 PM: Starting to download cache of 254.7KB
4:15:31 PM: Finished downloading cache in 119.957538ms
4:15:31 PM: Starting to extract cache
4:15:31 PM: Failed to fetch cache, continuing with build
4:15:31 PM: Starting to prepare the repo for build
4:15:32 PM: No cached dependencies found. Cloning fresh repo
4:15:32 PM: git clone [email protected]:oneshoewebsite/website2018
4:15:38 PM: Preparing Git Reference refs/heads/develop
4:15:39 PM: Starting build script
4:15:39 PM: Installing dependencies
4:15:40 PM: Downloading and installing node v8.12.0...
4:15:40 PM: Downloading https://nodejs.org/dist/v8.12.0/node-v8.12.0-linux-x64.tar.xz...
4:15:40 PM: 
#
4:15:40 PM:                                     1.9%
4:15:41 PM: 
#################################
4:15:41 PM: ######                                   54.9%
4:15:41 PM: 
####################################
4:15:41 PM: #################################### 100.0%
4:15:41 PM: Computing checksum with sha256sum
4:15:41 PM: Checksums matched!
4:15:43 PM: Now using node v8.12.0 (npm v6.4.1)
4:15:43 PM: Attempting ruby version 2.3.6, read from environment
4:15:44 PM: Using ruby version 2.3.6
4:15:44 PM: Using PHP version 5.6
4:15:44 PM: Started restoring cached node modules
4:15:44 PM: Finished restoring cached node modules
4:15:45 PM: Started restoring cached yarn cache
4:15:45 PM: Finished restoring cached yarn cache
4:15:45 PM: Installing yarn at version 1.3.2
4:15:45 PM: Installing Yarn!
4:15:45 PM: > Downloading tarball...
4:15:45 PM: [1/2]: https://yarnpkg.com/downloads/1.3.2/yarn-v1.3.2.tar.gz --> /tmp/yarn.tar.gz.fCkWccGqjP
4:15:45 PM:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
4:15:45 PM:                                  Dload  Upload   Total   Spent    Left  Speed
4:15:45 PM: 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
4:15:45 PM: 
100    91  100    91    0     0    985      0 --:--:-- --:--:-- --:--:--   989
4:15:45 PM: 0
4:15:45 PM:      0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0   608    0     0   2085      0 --:--:-- --:--:-- --:--:--  593k
4:15:45 PM: 1
4:15:45 PM: 00  865k  100  865k    0     0   991k      0 --:--:-- --:--:-- --:--:--  991k
4:15:45 PM: [2/2]: https://yarnpkg.com/downloads/1.3.2/yarn-v1.3.2.tar.gz.asc --> /tmp/yarn.tar.gz.fCkWccGqjP.asc
4:15:45 PM: 
100    95  100    95    0     0   2529      0 --:--:-- --:--:-- --:--:--  2529
4:15:45 PM: 
  0     0    0   612    0     0   4564
4:15:45 PM:     0 --:--:-- --:--:-- --:--:--  4564
4:15:46 PM: 1
4:15:46 PM: 00  1027  100  1027    0     0   4551      0 --:--:-- --:--:-- --:--:--  4551
4:15:46 PM: > Verifying integrity...
4:15:46 PM: gpg: Signature made Thu 02 Nov 2017 04:44:10 PM UTC using RSA key ID FD2497F5
4:15:46 PM: gpg: Good signature from "Yarn Packaging <[email protected]>"
4:15:46 PM: gpg: WARNING: This key is not certified with a trusted signature!
4:15:46 PM: gpg:          There is no indication that the signature belongs to the owner.
4:15:46 PM: Primary key fingerprint: 72EC F46A 56B4 AD39 C907  BBB7 1646 B01B 86E5 0310
4:15:46 PM:      Subkey fingerprint: 6A01 0C51 6600 6599 AA17  F081 46C2 130D FD24 97F5
4:15:46 PM: > GPG signature looks good
4:15:46 PM: > Extracting to ~/.yarn...
4:15:46 PM: > Adding to $PATH...
4:15:46 PM: > We've added the following to your /opt/buildhome/.profile
4:15:46 PM: > If this isn't the profile of your current shell then please add the following to your correct profile:
4:15:46 PM: export PATH="$HOME/.yarn/bin:$HOME/.config/yarn/global/node_modules/.bin:$PATH"
4:15:46 PM: 
4:15:46 PM: > Successfully installed Yarn 1.3.2! Please open another terminal where the `yarn` command will now be available.
4:15:46 PM: Installing NPM modules using Yarn version 1.3.2
4:15:47 PM: yarn install v1.3.2
4:15:47 PM: warning package.json: No license field
4:15:47 PM: warning [email protected]: No license field
4:15:47 PM: [1/4] Resolving packages...
4:15:48 PM: [2/4] Fetching packages...
4:15:48 PM: warning Pattern ["gatsby-link@next"] is trying to unpack in the same destination "/opt/build/.yarn_cache/v1/npm-gatsby-link-2.0.0-rc.2-e6f54bc9ae8f825136fbdb1ad789c2dbbf025d8a" as pattern ["gatsby-link@^2.0.0-rc.2"]. This could result in a non deterministic behavior, skipping.
4:16:07 PM: info [email protected]: The platform "linux" is incompatible with this module.
4:16:07 PM: info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
4:16:07 PM: [3/4] Linking dependencies...
4:16:07 PM: warning " > @babel/[email protected]" has unmet peer dependency "@babel/core@^7.0.0-0".
4:16:07 PM: warning "gatsby > mini-css-extract-plugin > schema-utils > [email protected]" has unmet peer dependency "ajv@>=5.0.0".
4:16:07 PM: warning " > [email protected]" has unmet peer dependency "jquery@>=1.8.0".
4:16:07 PM: warning " > [email protected]" has unmet peer dependency "eslint-plugin-jsx-a11y@^6.0.2".
4:16:14 PM: [4/4] Building fresh packages...
4:16:29 PM: success Saved lockfile.
4:16:29 PM: Done in 42.18s.
4:16:29 PM: NPM modules installed using Yarn
4:16:30 PM: warning package.json: No license field
4:16:30 PM: Started restoring cached go cache
4:16:30 PM: Finished restoring cached go cache
4:16:30 PM: unset GOOS;
4:16:30 PM: unset GOARCH;
4:16:30 PM: export GOROOT='/opt/buildhome/.gimme/versions/go1.10.linux.amd64';
4:16:30 PM: export PATH="/opt/buildhome/.gimme/versions/go1.10.linux.amd64/bin:${PATH}";
4:16:30 PM: go version >&2;
4:16:30 PM: export GIMME_ENV='/opt/buildhome/.gimme/env/go1.10.linux.amd64.env';
4:16:30 PM: go version go1.10 linux/amd64
4:16:30 PM: Installing missing commands
4:16:30 PM: Verify run directory
4:16:30 PM: Executing user command: npm run build:nl
4:16:30 PM: > [email protected] build:nl /opt/build/repo
4:16:30 PM: > GATSBY_LANGUAGE=nl-nl gatsby build
4:16:32 PM: success open and validate gatsby-config — 0.007 s
4:16:33 PM: success load plugins — 0.163 s
4:16:33 PM: success onPreInit — 0.764 s
4:16:33 PM: success delete html and css files from previous builds — 0.089 s
4:16:33 PM: success initialize cache — 0.008 s
4:16:34 PM: success copy gatsby files — 0.012 s
4:16:34 PM: success onPreBootstrap — 0.006 s
4:16:34 PM: Starting to fetch data from Prismic
4:16:35 PM: Fetch Prismic data: 1085.642ms
4:16:42 PM: success source and transform nodes — 8.514 s
4:16:44 PM: success building schema — 1.562 s
4:16:44 PM: success createPages — 0.214 s
4:16:44 PM: success createPagesStatefully — 0.328 s
4:16:44 PM: success onPreExtractQueries — 0.004 s
4:16:45 PM: success update schema — 1.102 s
4:16:46 PM: success extract queries from components — 0.352 s
4:17:30 PM: success run graphql queries — 44.577 s — 199/199 4.46 queries/second
4:17:30 PM: success write out page data — 0.006 s
4:17:30 PM: success write out redirect data — 0.001 s
4:30:04 PM: info bootstrap finished - 813.661 s
4:30:04 PM: success onPostBootstrap — 0.010 s
4:30:34 PM: success Building production JavaScript and CSS bundles — 30.560 s
4:30:40 PM: success Building static HTML for pages — 5.619 s — 198/198 108.75 pages/second
4:30:40 PM: info Done building in 849.863 sec
4:30:40 PM: Execution timed out after 15m0s
4:30:40 PM: Error running command: Command did not finish within the time limit
4:30:40 PM: Failing build: Failed to build site
4:30:40 PM: failed during stage 'building site': Command did not finish within the time limit
4:30:41 PM: Finished processing build request in 15m9.995337154s

Environment

System:
OS: macOS High Sierra 10.13.6
CPU: x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 10.7.0 - /usr/local/bin/node
Yarn: yarn install v0.24.6
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 74.20s. - ~/.node/bin/yarn
npm: 6.1.0 - /usr/local/bin/npm
Browsers:
Chrome: 69.0.3497.81
Firefox: 61.0.1
Safari: 11.1.2
npmPackages:
gatsby: next => 2.0.0-rc.15
gatsby-image: next => 2.0.0-rc.1
gatsby-link: next => 2.0.0-rc.2
gatsby-plugin-mailchimp: ^2.2.3 => 2.2.3
gatsby-plugin-react-helmet: next => 3.0.0-rc.1
gatsby-plugin-sharp: next => 2.0.0-rc.3
gatsby-plugin-styled-components: next => 3.0.0-rc.1
gatsby-source-prismic-lang: ^2.0.0-alpha.5 => 2.0.0-alpha.5
gatsby-transformer-remark: next => 2.1.1-rc.1
gatsby-transformer-sharp: next => 2.1.1-rc.3
npmGlobalPackages:
gatsby-cli: 1.1.58

bug

Source

jordyvanraaij

👍12

Most helpful comment

@DSchau

8379 Looks super promising ! That'd be a great step forward imho.

The problem here is, as far as I can tell, Gatsby will rebuild everything whenever you change a « core » file, including images

Could you share more information on this?

I think I misphrased this. Let me try again:

Gatsby will rebuild everything, including images, when you change a "core" file.

I don't get a cache invalidation when I change an image. I do when, as you mentioned, I edit package.json or gastby-*.js files. Sorry for that.

Also to be clear--I don't really see cache invalidation as the best solution to this problem. Generally--it's a fair assumption that a Gatsby app when built in a CI server will be given a fresh cache. I've seen some problems with that Netlify plugin caching things _too_ aggressively (e.g. a 1GB+ cache from tons of builds), so I'm not sure it's the solution I'd reach for most readily.

I see your point and it's something I can't say I had considered. I had my use case in mind which is rather basic: I have a server serving a Gatsby site. When I push code to a production branch, I like to grab the new code, run a build and then serve that new build.

What happens right now is: I edit the package.json file (I update a dependency, say React for example), I push my code and then get a 30 minutes (super CPU intensive, which I guess could have side effects if you're using this same box for other purposes) build time before the new version of the site is ready to be served. I find it a bit of a waste of time / power to recompute all images (and everything else, but images are the most expensive by far) because I bumped a dependency.

Same thing happens on my local machine too. With better hardware, it's faster of course (still takes a good 10/15 minutes), but every time I update a gastby-*.js file or package.json, I'm down for 15 minutes of Node hogging my CPU and me waiting to test the changes. Each time. So my React bump example above is actually 15 minutes (local machine) + 30 minutes (droplet) of just building before the new version is live.

Of course, I could only build locally and deploy compiled code directly, but I prefer to do it this way personally (for a few reasons which are beyond this - already too long - reply).

Not a major issue though, Gatsby is still one of the - if not THE - best webdev experience I've had. I absolutely love it.

Coriou on 13 Feb 2019

❤3

All 59 comments

Hmmm, that looks really goofy. Can you identify where it pauses during bootstrap? None of the individual steps take very long but the total bootstrap is 813 seconds.

KyleAMathews on 11 Sep 2018

@KyleAMathews is there a way to see what's happening in the bootstrap step? A debug mode of some sort?

I assume it does all the fancy image cropping etc in the bootstrap step?

jordyvanraaij on 11 Sep 2018

Yeah, I would say image processing -

Generating image thumbnails [==============================] 1690/1690 367.4 secs 100%

this is most likely cause why it pause before completing bootstrap:

4:17:30 PM: success write out redirect data — 0.001 s
4:30:04 PM: info bootstrap finished - 813.661 s

just it's not captured in terminal output on netlify

pieh on 11 Sep 2018

I am experiencing a similar problem on Netlify after converting an existing project to Gatby v2

Local build:

success open and validate gatsby-config — 0.071 s
success load plugins — 0.231 s
success onPreInit — 0.474 s
success delete html and css files from previous builds — 3.509 s
success initialize cache — 0.403 s
success copy gatsby files — 0.054 s
success onPreBootstrap — 0.004 s
success source and transform nodes — 1.046 s
success building schema — 0.409 s
success createPages — 0.481 s
success createPagesStatefully — 0.227 s
success onPreExtractQueries — 0.005 s
success update schema — 0.244 s
success extract queries from components — 0.743 s
success run graphql queries — 13.450 s — 74/74 5.50 queries/second
success write out page data — 0.009 s
success write out redirect data — 0.001 s
success onPostBootstrap — 0.002 s
info bootstrap finished - 23.29 s
success Building production JavaScript and CSS bundles — 41.191 s
success Building static HTML for pages — 8.799 s — 269/269 87.20 pages/second
info Done building in 73.704 sec

And Netlify:

9:46:41 AM: success open and validate gatsby-config — 0.008 s
9:46:41 AM: success load plugins — 0.307 s
9:46:42 AM: success onPreInit — 0.847 s
9:46:42 AM: success delete html and css files from previous builds — 0.126 s
9:46:42 AM: success initialize cache — 0.008 s
9:46:42 AM: success copy gatsby files — 0.013 s
9:46:42 AM: success onPreBootstrap — 0.004 s
9:46:44 AM: success source and transform nodes — 1.837 s
9:46:44 AM: success building schema — 0.498 s
9:46:46 AM: success createPages — 1.767 s
9:47:02 AM: success createPagesStatefully — 16.149 s
9:47:03 AM: success onPreExtractQueries — 0.940 s
9:47:04 AM: success update schema — 0.757 s
9:47:06 AM: success extract queries from components — 1.626 s
9:48:57 AM: success run graphql queries — 110.998 s — 258/258 2.32 queries/second
9:48:57 AM: success write out page data — 0.076 s
9:48:58 AM: success write out redirect data — 0.009 s
10:03:11 AM: info bootstrap finished - 992.867 s
10:03:11 AM: success onPostBootstrap — 0.007 s
10:04:48 AM: success Building production JavaScript and CSS bundles — 97.444 s
10:05:10 AM: success Building static HTML for pages — 20.208 s — 269/269 49.62 pages/second
10:05:10 AM: info Done building in 1110.841 sec
10:05:10 AM: Execution timed out after 15m0s
10:05:10 AM: Error running command: Command did not finish within the time limit
10:05:10 AM: Failing build: Failed to build site
10:05:10 AM: failed during stage 'building site': Command did not finish within the time limit
10:05:10 AM: Finished processing build request in 20m46.304813094s

Edit: Further investigation using the Netlify build image locally shows that the image processing is what is causing the build to take so long. In Gatsby v1 we had ~1200 images that were processed and now after upgrading to v2 there are ~2900.

azamatsmith on 18 Sep 2018

I opened a different issue that has since been closed in favour of this one. #8611 for reference and while I agree that the issues are very likely to be related I thought I would post the difference in my build result as it is not hitting the netlify time limit and instead dying at the static HTML Generation.

1:05:36 AM: success createPages — 0.208 s
1:05:36 AM: success createPagesStatefully — 0.047 s
1:05:36 AM: success onPreExtractQueries — 0.007 s
1:05:36 AM: success update schema — 0.815 s
1:05:36 AM: success extract queries from components — 0.748 s
1:05:56 AM: success run graphql queries — 19.567 s — 127/127 6.49 queries/second
1:05:56 AM: success write out page data — 0.006 s
1:05:56 AM: success write out redirect data — 0.001 s
1:13:16 AM: info bootstrap finished - 474.601 s
1:13:16 AM: done generating icons for manifest
1:13:16 AM: success onPostBootstrap — 0.187 s
1:13:39 AM: success Building production JavaScript and CSS bundles — 22.622 s
1:13:43 AM: error Building static HTML for pages failed
1:13:43 AM: See our docs page on debugging HTML builds for help https://goo.gl/yL9lND
1:13:43 AM:    9 |   <div className="chevron__banner-container">
1:13:43 AM:   10 |     <div className="chevron__banner-web">
1:13:43 AM: > 11 |       <Img fluid={props.image.childImageSharp.fluid} />
1:13:43 AM:      |                                               ^
1:13:43 AM:   12 |       <div className="chevron__banner-text">
1:13:43 AM:   13 |         <h4 className="chevron__banner-subtitle">{props.subtitle}</h4>
1:13:43 AM:   14 |         <div className="chevron__banner-title">{props.title}</div>
1:13:43 AM: 
1:13:43 AM:   WebpackError: TypeError: Cannot read property 'fluid' of null

williamtstanley on 28 Sep 2018

@jordyvanraaij @williamtstanley I was able to bypass this issue by using this plugin: gatsby-plugin-netlify-cache.

It doesn't solve the issue of the images taking so long to process, but it reduced my build times to ~5 minutes and does not trigger the time limit error. The key is to getting this plugin in the project's master branch before the image count gets so big that Netlify fails.

azamatsmith on 28 Sep 2018

Unfortunately this did not resolve my issue. After playing with my build a bit more I think I may have a different problem. Develop is always fine but even on a pretty powerful machine my builds are failing consistently on larger lists of images.

I am currently considering if there isn't some issue with my source plugin. A race condition/unresolved Promise or something... why it works in development and not production I don't get other than all the image processing happening all at once being the huge difference.

williamtstanley on 28 Sep 2018

Was testing some changes and noticed something interesting in the build output. It started the Building production JS step before it was finished generating the thumbnails. Not sure its totally pertinent but it certainly was strange.

success createPages — 0.136 s
success createPagesStatefully — 0.028 s
success onPreExtractQueries — 0.002 s
success update schema — 0.397 s
success extract queries from components — 0.377 s
success run graphql queries — 5.827 s — 126/126 21.63 queries/second
success write out page data — 0.003 s
success write out redirect data — 0.000 s
Generating image thumbnails [==============================] 2934/2934 223.0 secs 100%

info bootstrap finished - 231.628 s

⠂ onPostBootstrapdone generating icons for manifest
success onPostBootstrap — 0.103 s
success Building production JavaScript and CSS bundles — 17.892 s
Generating image thumbnails [==============================] 3146/3146 244.3 secs 100%

info bootstrap finished - 252.865 s

⡀ Building static HTML for pagesdone generating icons for manifest
success onPostBootstrap — 0.093 s

error Building static HTML for pages failed

See our docs page on debugging HTML builds for help https://goo.gl/yL9lND

  14 |     >
  15 |       <div className="trainers__card-image">
> 16 |         <Img fluid={athleteImageNode.childImageSharp.fluid} />

williamtstanley on 29 Sep 2018

I just want to report that I have the same problem.

Gatsby builds were all nice and sweet until I started manipulating images. I only have a few images for the whole site (roughly 50), but with the different sizes, the sqip versions and all, I end up with 700 images...

So, I understand it takes a long time to process (though, should it be THAT long ?). But what I believe is even more of a problem is how it fails to use cache correctly.

I have a Caddy server running, waiting for push to my git server to rebuild and deploy the site. I feel like each push will trigger an entire re-generation of the thumbnails which, on the cheapest Digital Ocean droplet, takes about 15-20 minutes.

When I see you guys reporting 3146 images generated in 244 seconds I'm kinda jealous. Maybe I'm doing something wrong ?

success extract queries from components — 0.315 s
success run graphql queries — 942.563 s — 19/19 0.02 queries/second
success write out page data — 0.011 s
success write out redirect data — 0.001 s
Generating image thumbnails [==============================] 760/760 1204.8 secs 100%

info bootstrap finished - 1216.964 s

Coriou on 29 Sep 2018

@Coriou The Gatsby build only takes 244 seconds when the .cache and public directories are present from previous builds. During a fresh build (with no .cache or public directory) it takes so long that it times out.

If you figure out how to persist those directories, or if you write a pre-build and post-build script that recovers and stores those directories, I'm sure your problem will go away on your DIgital Ocean servers.

azamatsmith on 1 Oct 2018

@azamatsmith Currently working on this issue for my project. I figured out that it was the image transformations that were taking so long (makes sense). Also, Gatsby invalidates cache quite often (can be triggered by different things, like editing your gatsby-node file). I guess I could tackle the cache clearing issue (make sure transformed images are kept for example) but I took a different approach.

What I'm trying to do is to write my own transformer that would be compatible with gatsby-image but instead of manipulating images locally, it'd rely on a remote service (looking at Pixboost right now). This would require no image manipulation at build, thus drastically improving build times regardless of cache.

Coriou on 1 Oct 2018

👍1

@Coriou In our builds (2900 images), we found that Gatsby does not invalidate the processed image cache in subsequent builds and therefore does not have to re-process (build thumbnails) for them (as long as we persist the directories that I mentioned).

azamatsmith on 1 Oct 2018

@Coriou we're working on this!

See #8435 and #8379 (which sorta depends on #8435). Hope to have something soon!

DSchau on 1 Oct 2018

@azamatsmith Maybe I'm doing something wrong then. I do never delete those directories, yet the build process will take forever if I edit something that triggers some cache invalidation (again, for me making any sort of edit to gatsby-node.js, which I do often, will trigger this invalidation).

@DSchau Great, great news ! This looks like it would solve my issue. Thank you :)

Coriou on 1 Oct 2018

I'm having a similar issue but my builds fails like this (sometimes it passes though):

6:09:03 PM: error GraphQL Error Unknown field `image` on type `Posts`
6:09:03 PM:   file: /opt/build/repo/src/templates/category.jsx
6:09:03 PM:   150 |       edges {
6:09:03 PM:   151 |         node {
6:09:03 PM:   152 |           id
6:09:04 PM: > 160 |           image {
6:09:04 PM:       |           ^

oskareke on 4 Oct 2018

I'm having the exact same issue as @williamtstanley described in #8611 — my problem isn't hitting the Netlify time limit, it's instead dying at the static HTML Generation.

Everything was fine until I started playing with image generation through gatsby-image.


info bootstrap finished - 36.591 s

success onPostBootstrap — 0.004 s
success Building production JavaScript and CSS bundles — 11.309 s

error Building static HTML for pages failed

See our docs page on debugging HTML builds for help https://goo.gl/yL9lND

  23 |     <article className="pb5">
  24 |       {helmet || ""}
> 25 |       <Img fluid={featuredImage.childImageSharp.fluid} />
     |                                 ^
  26 |
  27 |       <h1>
  28 |         {title}


  WebpackError: TypeError: Cannot read property 'childImageSharp' of null

lol-russo on 27 Oct 2018

@lol-russo I kept getting errors like that when doing my createRemoteFileNodes inside a getNodes().forEach loop. Moving all of them to exports.onCreateNode got rid of the problem for me.

oskareke on 28 Oct 2018

I'm having the exact same issue as @williamtstanley described in #8611 — my problem isn't hitting the Netlify time limit, it's instead dying at the static HTML Generation.

Everything was fine until I started playing with image generation through gatsby-image.
info bootstrap finished - 36.591 s

success onPostBootstrap — 0.004 s
success Building production JavaScript and CSS bundles — 11.309 s

error Building static HTML for pages failed

See our docs page on debugging HTML builds for help https://goo.gl/yL9lND

  23 |     <article className="pb5">
  24 |       {helmet || ""}
> 25 |       <Img fluid={featuredImage.childImageSharp.fluid} />
     |                                 ^
  26 |
  27 |       <h1>
  28 |         {title}


  WebpackError: TypeError: Cannot read property 'childImageSharp' of null

@lol-russo This particular error might be due to the fact that data is not present for the featuredImage field on all nodes. I found that I have to default nodes for data with holes in it for Gatsby to build completely.

I would verify that every record has that field populated first. If that does end up being your problem, I'd either fix the data, or create a plugin to manage the data as it is being consumed.

willcode4food on 5 Nov 2018

👍1

I'm having the exact same issue as @williamtstanley described in #8611 — my problem isn't hitting the Netlify time limit, it's instead dying at the static HTML Generation.
Everything was fine until I started playing with image generation through gatsby-image.
info bootstrap finished - 36.591 s

success onPostBootstrap — 0.004 s
success Building production JavaScript and CSS bundles — 11.309 s

error Building static HTML for pages failed

See our docs page on debugging HTML builds for help https://goo.gl/yL9lND

  23 |     <article className="pb5">
  24 |       {helmet || ""}
> 25 |       <Img fluid={featuredImage.childImageSharp.fluid} />
     |                                 ^
  26 |
  27 |       <h1>
  28 |         {title}


  WebpackError: TypeError: Cannot read property 'childImageSharp' of null
@lol-russo This particular error might be due to the fact that data is not present for the featuredImage field on all nodes. I found that I have to default nodes for data with holes in it for Gatsby to build completely.

I would verify that every record has that field populated first. If that does end up being your problem, I'd either fix the data, or create a plugin to manage the data as it is being consumed.

i had the same issue and adding an image to all the nodes fixed the issue for me

HabibaGadalla on 2 Jan 2019

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

gatsbot[bot] on 10 Feb 2019

Hey,

I am facing the same issue.
This issue is not stale

Thanks for all the help.

mudit2108 on 13 Feb 2019

@gatsbyjs/core is this something we can fix? I'm not super familiar with Netlify so I'm unsure there are ways to save specific folders to a cache.

If it works fine on local but slow on Netlify it smells like slow hardware.

wardpeet on 13 Feb 2019

My take on this is that Gatsby needs to be smarter when clearing cache, especially images. The problem here is, as far as I can tell, Gatsby will rebuild everything whenever you change a « core » file, including images.

This is what takes forever. I don’t use netlify but I have a similar build set up on a $5 DO droplet and my rebuild when cache is cleared takes about 30 minutes (most of which is just image transformation).

I think Gatsby should try to preserve transformed images cache as long as it can, this would most likely solve this issue as well as greatly reduce build times when you just update dependencies or a « core » file used by Gatsby.

Coriou on 13 Feb 2019

👍3

@Coriou there's this open PR (#8379) that's also gotten a bit stale--the intent is to solve that very issue though.

Also to be clear--I don't really see cache invalidation as the best solution to this problem. Generally--it's a fair assumption that a Gatsby app when built in a CI server will be given a fresh cache. I've seen some problems with that Netlify plugin caching things _too_ aggressively (e.g. a 1GB+ cache from tons of builds), so I'm not sure it's the solution I'd reach for most readily.

The problem here is, as far as I can tell, Gatsby will rebuild everything whenever you change a « core » file, including images

Could you share more information on this? This generally doesn't seem to be the case. The cache invalidation logic for Gatsby looks something like:

Perform an md5 hash on package.json; if it changes, delete cache
Perform an md5 hash on gatsby-*.js files; if one changes, delete cache

DSchau on 13 Feb 2019

@DSchau

8379 Looks super promising ! That'd be a great step forward imho.

The problem here is, as far as I can tell, Gatsby will rebuild everything whenever you change a « core » file, including images

Could you share more information on this?

I think I misphrased this. Let me try again:

Gatsby will rebuild everything, including images, when you change a "core" file.

I don't get a cache invalidation when I change an image. I do when, as you mentioned, I edit package.json or gastby-*.js files. Sorry for that.

Also to be clear--I don't really see cache invalidation as the best solution to this problem. Generally--it's a fair assumption that a Gatsby app when built in a CI server will be given a fresh cache. I've seen some problems with that Netlify plugin caching things _too_ aggressively (e.g. a 1GB+ cache from tons of builds), so I'm not sure it's the solution I'd reach for most readily.

Of course, I could only build locally and deploy compiled code directly, but I prefer to do it this way personally (for a few reasons which are beyond this - already too long - reply).

Not a major issue though, Gatsby is still one of the - if not THE - best webdev experience I've had. I absolutely love it.

Coriou on 13 Feb 2019

❤3

What happens right now is: I edit the package.json file (I update a dependency, say React for example), I push my code and then get a 30 minutes (super CPU intensive, which I guess could have side effects if you're using this same box for other purposes) build time before the new version of the site is ready to be served. I find it a bit of a waste of time / power to recompute all images (and everything else, but images are the most expensive by far) because I bumped a dependency.

This is the _key issue_ and I agree very strongly! We need to take another look at #8379 because we definitely want cache invalidation, but invalidating images (and other heavy processes) if e.g. some unrelated plugin changes seems unnecessary.

Although--one more time--this really impacts local development more than CI/Netlify. I don't think I'd strongly encourage caching the cache/public folders with that plugin because of the reasons I specified earlier!

DSchau on 13 Feb 2019

We don't ever delete images in the public folder as they are reliably cacheable. @coriou are you deleting the public folder?

KyleAMathews on 13 Feb 2019

Even if you delete .cache, gatsby-plugin-sharp checks if a thumbnail exists before it tries to recreate it.

KyleAMathews on 13 Feb 2019

@KyleAMathews

@Coriou are you deleting the public folder?

Never !

Even if you delete .cache, gatsby-plugin-sharp checks if a thumbnail exists before it tries to recreate it.

I also use gatsby-transformer-sqip (which is also much more expensive than Sharp, by design), could this be the reason why I constantly get a full rebuild of everything ?

Coriou on 13 Feb 2019

Ah! It's very possible actually that sqip doesn't cache correctly. It wasn't built by us and afaik, doesn't get a lot of usage, so might need some more love.

The sharp plugins definitely do cache correctly.

KyleAMathews on 13 Feb 2019

Well, it does check against cache.

On a side note, I thought this plugin would be used a lot, it's super cool.

Coriou on 13 Feb 2019

I am running into the same problem with gatsby-transformer-sqip. For me it seems to be limited to queries executed in createPages. Even if there are only 5 images processed with SQIP I end up with a timeout after 30 minutes. Meanwhile i have 20+ images in page queries that work just fine, From what i've read this must mean that some process does not quit correctly in this case but I have no idea on how to debug this further,

Oops - nevermind. I figured it out, I had an extra resolve() call in the createNode function. Once i removed that it started building as expected.

DigitalGoldfish on 15 Feb 2019

I am getting this issue as well (generating 3561 thumbnails) which takes way to long on Netlify (works fine locally - even after deleting the .cache and public folders).

I can't see the full log in Netlify because I am getting this:
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 drain listeners added. Use emitter.setMaxListeners() to increase limit

Here are the last few lines of the log:

```12:40:53 PM: info Done building in 1391.178 sec
12:40:55 PM: Execution timed out after 15m0s
12:40:55 PM: Error running command: Command did not finish within the time limit
12:40:55 PM: Failing build: Failed to build site
12:40:56 PM: failed during stage 'building site': Command did not finish within the time limit
12:40:56 PM: Finished processing build request in 24m4.430100964s

bogdancss on 4 Apr 2019

I've added require('events').EventEmitter.defaultMaxListeners = 100 to gatsby-node to stop the MaxListenersExceededWarning error from showing and here's the build log:

```3:29:19 PM: success building schema — 1.771 s
3:29:19 PM: success createPages — 0.371 s
3:29:20 PM: success createPagesStatefully — 0.100 s
3:29:20 PM: success onPreExtractQueries — 0.005 s
3:29:20 PM: success update schema — 0.061 s
3:29:20 PM: success extract queries from components — 0.873 s
3:32:46 PM: success run graphql queries — 205.678 s — 249/249 1.21 queries/second
3:32:46 PM: success write out page data — 0.017 s
3:32:46 PM: success write out redirect data — 0.001 s
3:46:17 PM: success onPostBootstrap — 0.228 s
3:46:17 PM: info bootstrap finished - 1118.78 s
3:47:00 PM: success Building production JavaScript and CSS bundles — 42.470 s
3:47:31 PM: success Building static HTML for pages — 30.964 s — 245/245 30.36 pages/second
3:47:31 PM: (node:1254) [DEP0013] DeprecationWarning: Calling an asynchronous function without callback is deprecated.
3:47:31 PM: (node:1254) [DEP0013] DeprecationWarning: Calling an asynchronous function without callback is deprecated.
3:47:31 PM: Found 114 files in public directory with 77 already cached files.
3:47:36 PM: Found 44 files in .cache directory with 42 already cached files.
3:47:39 PM: plugin-netlify-cache: Netlify cache refilled
3:47:57 PM: ⚠ WARN: public/index.html: Multiple ApplicationManifest relations. Only one per document is allowed. See http://www.w3.org/TR/appmanifest/#h-note4
3:47:57 PM: ⚠ WARN: ENOENT: no such file or directory, open 'public/workbox-v3.6.3/packages/workbox-sw/browser.mjs'
3:47:57 PM: Including assets:
3:47:57 PM: public/workbox-v3.6.3/workbox-sw.js.map
3:47:57 PM: /bin/sh: 1: pyftsubset: not found
3:47:57 PM: Generated public/sw.js, which will precache 12 files, totaling 797373 bytes.
3:47:57 PM: Found 114 files in public directory with 114 already cached files.
3:48:02 PM: Found 44 files in .cache directory with 44 already cached files.
3:48:04 PM: plugin-netlify-cache: Netlify cache refilled
3:48:04 PM: info Done building in 1226.208 sec
3:48:05 PM: Execution timed out after 15m0s
3:48:05 PM: failed during stage 'building site': Command did not finish within the time limit
3:48:05 PM: Error running command: Command did not finish within the time limit
3:48:05 PM: Failing build: Failed to build site
3:48:06 PM: Shutting down logging, 1 messages pending

bogdancss on 4 Apr 2019

@b0gd4n I can offer a solution that worked for me. It is very "hacky" though.

The idea behind it was that I needed to prepopulate the Netlify cache with my local cache so that future builds would pass.

Do a Gatsby build locally
Check your public and .cache directories into git.
I modified the Netlify cache plugin to prepopulate the Netlify cache with the checked in .cache and public dirs. I named it prebuild.js Here is a gist.
Updated your build script to node ./scriptLocation/prebuild.js && your gatsby build command

Your build should pass. Make sure that the branch gets merged to master so that the cache will be updated on future builds.

Don't forget to remove the .cache and public dirs from git afterwards.

Like I said, super hacky but it worked for me when nothing else would. I no longer have this issue so I don't know if there are any long term side effects from this approach. It should be used as a last resort.

azamatsmith on 4 Apr 2019

@azamatsmith I tried deploying from local with the same though in mind - to get the Netlify cache to store all thumbs and then there should never be so many thumbs to generate, so all future builds should work (until you specifically clear cache), but didn't really work.

Did not realise that you need to commit the ignored folders and modify the plugin to get it to run.

Will give this a try - thanks!

bogdancss on 4 Apr 2019

@azamatsmith after pushing the .cache & public folders, do I leave the build command modifies, or revert that as well? Also, do I need to remove the gatsby-plugin-netlify-cache plugin?

bogdancss on 4 Apr 2019

@b0gd4n Keep the gatsby-plugin-netlify-cache plugin and revert the build command back to what it was.

🤞 Hope this work for ya!

azamatsmith on 4 Apr 2019

@azamatsmith it did - thanks. Not ideal, but it worked. Will still want to actually fix this, but will do for now.

bogdancss on 4 Apr 2019

🎉1

@b0gd4n @azamatsmith just out of curiosity, are you guys using gatsby-plugin-sqip ?

Coriou on 4 Apr 2019

@Coriou No, I'm not using that plugin.

azamatsmith on 5 Apr 2019

👍1

@williamtstanley I had same issue as you described. After update .md file via netlify-cms I had that error when gatsby build.
I have hack to solve it.
I'm removing from cache dir file: .cache/redux.state and then build works well.

jcieslar on 17 Apr 2019

any progress on this?

bogdancss on 29 May 2019

Hello, I'm experiencing the same issue. any updates?

gilbertlucas46 on 2 Jun 2019

Okay, So I fixed mine by doing this

Clear cache and deploy site!

gilbertlucas46 on 2 Jun 2019

👍1

We did some changes in our image processing plugins but unsure if it actually relates to this issue. It seems like clearing your cache might fix the issue. Would love some feedback of some people struggling.

wardpeet on 3 Jun 2019

👍1

@wardpeet no - that didn't do much for me. Clearing cache also does not help. I tried committing the .cache & public folders as well - that does do it either.

bogdancss on 4 Jun 2019

tried this on circleci - it runs out of memory there:

```
Generating image thumbnails [] 1650/3708 338.3 secs 44%
Killed
error Command failed with exit code 137.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Exited with code 137

Hint: Exit code 137 typically means the process is killed because it was running out of memory
Hint: Check if you can optimize the memory usage in your app
Hint: Max memory usage of this container is 4283080704
according to /sys/fs/cgroup/memory/memory.max_usage_in_bytes

bogdancss on 4 Jun 2019

@azamatsmith

Thanks for your solution. I'm trying to run your prebuild.js script but end up with this error and my build still fails. Any suggestions?

11:04:20 PM: Prebuild - Checking Netlify server
11:04:20 PM: (node:1361) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, scandir '/opt/build/cache/public'
11:04:20 PM: (node:1361) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
11:04:20 PM: (node:1361) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
11:04:21 PM: successfully removed cache dir

aks1994 on 11 Jun 2019

To help us best begin debugging the underlying cause, it is incredibly helpful if you're able to create a minimal reproduction. This is a simplified example of the issue that makes it clear and obvious what the issue is and how we can begin to debug it.

If you're up for it, we'd very much appreciate if you could provide a minimal reproduction and we'll be able to take another look.

Thanks for using Gatsby! 💜

wardpeet on 12 Jun 2019

You could optimize it further:

set concurrentRequests in gatsby-config.js for gatsby-source-wordpress
set environnement variable GATSBY_CPU_COUNT=logical_cores to Netlify > Build & Deploy > Environnement.
use gatsby-plugin-netlify-cache in your gatsby-config.js (at the end of the plugins)
ensure the responses of your WordPress wp-json results are cached on the server.

sebastienfi on 19 Jun 2019

Same issue, @azamatsmith I tried your approach, but since i have added one plugin it clears the cache directories 😢
Screenshot 2019-08-31 at 8 46 57 PM

nishanBende on 31 Aug 2019

I'm also running into this issue:

I tried to deploy yesterday, and my builds were hanging. I ended up just stepping away. I checked back today, and it looks like they finally timed out:

6:36:42 PM: success Building static HTML for pages - 4.725s - 21/21 4.44/s
6:36:42 PM: Generated public/sw.js, which will precache 8 files, totaling 378760 bytes.
6:36:42 PM: info Done building in 1210.550043119 sec
6:36:42 PM: Execution timed out after 15m0s
6:36:42 PM: Error running command: Command did not finish within the time limit
6:36:42 PM: Failing build: Failed to build site
6:36:42 PM: failed during stage 'building site': Command did not finish within the time limit
6:36:42 PM: Finished processing build request in 21m5.220289707s

I'm noticing that when I delete .cache and /public I can reproduce the issue locally (although I can't get my laptop to time out):

success Building production JavaScript and CSS bundles - 6.408s
success Rewriting compilation hashes - 0.004s
warn code block or inline code language not specified in markdown. applying generic code block
success run queries - 11.185s - 23/23 2.06/s
 [==================------------] 1716/2891 109.6 s 59% Generating image thumbnails

My images are just hosted locally right now. If I use a CMS like Dato or Contentful, will I still have this problem? I'm guessing it's just a hardware problem -- I'm on the free tier of Netlify. Since it's just my blog, I'm considering just getting rid of all the images for my blog posts!

maecapozzi on 23 Nov 2019

Netlify limits your build time so it's not Gatsby but netlify. You might want to crop your images a bit yourself so it doesn't have to load big images to do the transformations. Using directly from dato or contentful would fix your issue but you won't have all the benefits gatsby-image brings.

wardpeet on 20 Dec 2019

If you're up for it, we'd very much appreciate if you could provide a minimal reproduction and we'll be able to take another look.

Thanks for using Gatsby! 💜

wardpeet on 20 Dec 2019

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

github-actions[bot] on 9 Jan 2020

Got the same issue as mentionned recently. I've tried the solutions proposed but that didn't worked well for some reasons.

I've followed @wardpeet advices and wrote a script to resize all my images (besides hero) using the preview system from apple, and that worked well without sacrificing too much the quality. All my images are way smaller in weight now and the netlify build is not timing out anymore.

Clearly not the best solution, rather hacky, but un-block for now until a proper fix is made. My script is here https://gist.github.com/PBRT/da3d7610b5ecdd2460565d62f03fb712 in the meantime (nothing crazy) if that can help someone.

PBRT on 13 Jan 2020

This occurs because Netlify limits build time to 15 minutes by default. Some options here

Use gatsby-plugin-netlify-cache which will persist Gatsby's cache on netlify and reduce the time taken for consequent builds
Use smaller images (large images tend to be the number 1 cause of slow builds)

Since this isn't strictly a Gatsby issue, I'll be closing this for now. Thank you so much everyone!

sidharthachatterjee on 16 Jan 2020

We already have credit card in and paying for build minutes, just had 4 builds fail due to this 15mins limit (1 hour of build time wasted which we'll have to pay for...) please get our limit up to 30 mins too, we have too many routes to be limited to 15m.
Site: bitcompare
https://bitcompare.net
Thanks