Gatsby build occasionally time out after "Caching JavaScript and CSS webpack compilation"

[robinmetral]

Preliminary Checks

• This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/gatsbyjs/gatsby/issues
• This issue is not a question, feature request, RFC, or anything other than a bug report directly related to Gatsby. Please post those things in GitHub Discussions: https://github.com/gatsbyjs/gatsby/discussions

Description

About a month ago, builds of my Gatsby site started failing in GitHub Actions.

For context, this Gatsby site is a minimal example using my gatsby-source-s3 plugin, that I use for testing the plugin end-to-end.

Here's from an example of a failed build:

# ℹ️ omitted earlier logs, check out the link above to view the entire output
success run page queries - 13.660s - 1/1 0.07/s # 👈 this is after all nodes were sourced from S3, so I don't think the problem is with my plugin
success write out requires - 0.011s
success Building production JavaScript and CSS bundles - 9.577s
success Rewriting compilation hashes - 0.005s
success Writing page-data.json files to public directory - 0.017s - 1/1 57.50/s
success Caching JavaScript and CSS webpack compilation - 13.059s # 👈 this is where is hangs
Error: Timed out waiting for: http://localhost:9000 # 👈 this is the timeout from cypress. I've also increased it to see if it just took too long, but that was not the issue

At first, all builds were failing, and in the last week it seems that some of them are passing again while others are still failing.

I'm not sure what's happening here, as there are no helpful logs in the build output. A local gatsby develop works completely fine. The occasional passing build seem to rule out issues in my project or in other dependencies. I also asked on discord but it didn't seem like anyone was having the same issue.

Any thoughts on:

• what the issue is here
• how I could debug this—I haven't found anything on the docs about this

Thank you!

A note about the reproduction link 👇 I am aware that the issue template says "Do not link to your actual project", but in my case this example site is exactly a minimal example, since the only thing is does is pulling images from S3. I added the GH Action output there, here's the link to the actual source although I doubt that it will be helpful.

Reproduction Link

https://github.com/robinmetral/gatsby-source-s3/runs/3912139392?check_suite_focus=true

Steps to Reproduce

1. Visit the link above to see the failing build output. I cannot reliably reproduce this locally, as mentioned in the summary.

Expected Result

gatsby build should not time out

Actual Result

gatsby build is flaky and unreliable, and regularly hangs in CI envs

Environment

My local environment is not the issue here, this is failing on a clean GH Actions machine with:

• Ubuntu 20.04 LTS
• Latest Node 14
• Gatsby 3

Config Flags

No response

[vyasdhairya]

updates the husky config after v7 (ensures the commit hook works)
updates the example site to work with the new gatsby image (address the Gatsby deprecation warning)
follows-up on chore(ci): pin example site dependencies by committing the lockfile #527 by fixing how the linking of the local package is handled in CI

[robinmetral]

Yes these are commit messages in the project but I don't see the relevance 😄

[robmarshall]

I am also having this issue. I feel (although not sure) that these are caused by sharp plugin. gatsby-transformer-sharp & gatsby-plugin-sharp maybe.

edit:
Reverting both of the above plugins to 3.12.0 meant the builds passed.

[LekoArts]

Hi, thanks for the issue!

Did you try out the @next versions of the plugins and Gatsby itself? Can you definitely pinpoint it to the sharp plugins? Can you bisect between which version it happened?

[robinmetral]

I feel (although not sure) that these are caused by sharp plugin. gatsby-transformer-sharp & gatsby-plugin-sharp maybe.

Pinning these dependencies to 3.12.0 does seem to fix it for me as well. I'll wait a couple days to be positive about this, since it was not always failing, just generally flaky.

Did you try out the @next versions of the plugins and Gatsby itself? Can you definitely pinpoint it to the sharp plugins? Can you bisect between which version it happened?

I haven't tried next yet, happy to do it. But unless there was a known issue that was solved in a prerelease, i don't see how it would be any different. I'll give it a spin anyways.

As for whether we can definitely pinpoint this to sharp, I'll hand this to @robmarshall—I'm not sure how you figured this out (💯). But if it is indeed related to the gatsby monorepo version bumps, in my project I saw the failures start to happen on the day this PR was merged, i.e. the bump from 3.13 to 3.14.

[robmarshall]

i.e. the bump from 3.13 to 3.14.

I can confirm the issue is introduced by gatsby-plugin-sharp 3.14. Bumping it to next does not solve the problem.

[cameronbraid]

I hit the same issue.

With gatsby-plugin-sharp and gatsby-transformer-sharp at 3.14 I get : Caching JavaScript and CSS webpack compilation - 2158.531s

With gatsby-plugin-sharp and gatsby-transformer-sharp at 3.12 I get : Caching JavaScript and CSS webpack compilation - 40.313s

[sirichards]

I had the same issue, rolling back to version 3.13.0 for gatsby-plugin-sharp and gatsby-transformer-sharp fixed it for me. Although i did get caught out by the ^ symbol in my package.json, so I went from "^3.13.0" to "3.13.0"