Gatsby site builds locally, but fails on netlify

I’m looking for help in fixing my broken netlify build. I use gatsby. An earlier version deployed effectively. Recent changes build locally but fail on netlify, and I’d like help to fix this. Not sure I can use Netlify after all… :frowning:

The latest build fail, after setting up dependabot, now results in this log:

11:31:17 AM: Build ready to start
11:31:24 AM: build-image version: 9cade8af58c2cf3a17a1e9433d2e979149488837
11:31:24 AM: build-image tag: v3.3.5
11:31:24 AM: buildbot version: 6067c60f3bc043bb6b9ee9b57c85b10029c65bfd
11:31:24 AM: Fetching cached dependencies
11:31:24 AM: Starting to download cache of 254.9KB
11:31:24 AM: Finished downloading cache in 245.683906ms
11:31:24 AM: Starting to extract cache
11:31:24 AM: Failed to fetch cache, continuing with build
11:31:24 AM: Starting to prepare the repo for build
11:31:25 AM: No cached dependencies found. Cloning fresh repo
11:31:25 AM: git clone
11:31:40 AM: Preparing Git Reference refs/heads/master
11:31:41 AM: Starting build script
11:31:41 AM: Build command unable to start
11:31:41 AM: Error running command: fork/exec /usr/local/bin/build: no such file or directory
11:31:41 AM: Failing build: Failed to build site
11:31:41 AM: failed during stage ‘building site’: fork/exec /usr/local/bin/build: no such file or directory
11:31:41 AM: Finished processing build request in 17.496151149s


It looks like you’re build command is set to ‘build’. As mentioned in our doc, that won’t work. You’ll need to change your build command to something else.

Hi Dennis,
Thank you so much for the feedback. Since posting this I have installed gatsby-cli locally, so that it is recorded in the package.json file, and is pulled into the deployment process on netlify.

My problem now is that the build seems to loop through the 170 or so mdx files a couple times, but with no error. The logging shuts down eventually, and indicates that “993 messages are pending”. So I think this is an issue with the logging service that netlify uses. But that issue just masks the underlying issue I’m having with the build.

Why doesn’t netlify just pull the already built files that I generated locally, which are stored in my git repo’s “/public” build folder?

The logging is paused if you’re build is too verbose, one way to make sure to you see the rest of your build output logs is to add && sleep 300 to your build command so our buildbot will wait for the rest of the log lines.

Regarding why we don’t just take the public/ folder and deploy it, our buildbot does not do anything unless you tell it to, with the exception of some dependency installation. If you have your build site in the public/ folder already, you can remove your build command and check that your public/ folder is set as your publish directory. That’ll skip any building and just take the folder as-is and deploys it.

Thank you, Dennis! So skipping the build is an option; super!
I tried adding sleep directive to the build command, but it did not yield more log info.

I didn’t realize that the Build process could be turned off! I should have tried that too.

I did find a workaround though. 2 Actually. Gatsby Cloud has a service called Gatsby Builds, which builds the project correctly and quickly, and has a simple config for deploying to Netlify edge servers. So I’m doing that.

I also got the project to build correctly on

Some additional builds were triggered by Dependabot adding pull requests to my Git repo. Those failed but started chewing up more of my build minutes. At 303 minutes, I decided to delete the failing project. But that generated a $7 bill. (Any chance I can get that zero’d out since the logging issue has not been resolved and is cloaking the cause of the build fail?)

I’d like to keep my current pipeline, where upon Git repo update, Gatsby Builds does the build, and then deploys to Netlify. But Netlify is now threatening to delete my project.

Thanks, in advance, for your help!

In the future, please don’t post identical requests in multiple threads - wastes your time and slows our team down in helping you.

We’ve opened a helpdesk case for you on this exact topic from your other identical query and we’ll get that taken care of early next week via that email thread.