Ok, now the original issue is back - which is that the deploy log seems to show the mdx frontmatter endlessly streaming through the log, like it’s in an endless loop or something. I used MDX to enter in my “content” which is metadata about artwork. Each artwork page also has a ‘navlist’ component which is a list of links to all 167 other artwork pages (which use the mdx frontmatter to compile data).
The netlify best practices indicate that large media (images) would be better hosted by something like cloudinary.
I also noticed that the deploy log has 88,000+ lines and seems to be timing out. I think the last deploy too 40+ minutes before failing. What could induce these “loopy” build behaviors?
The site is basically just 170 pages with large art images and each page has a link list to every other page. Could that cause this huge build “loop” somehow?
I’m not sure I have a definitive answer for you - but something is definitely up with your build, nothing like what you are describing should take that long to compile.
I took at look at the log, and while I can’t speak to whether or not the way you are going about this is kosher or not (not a gatsby expert, sorry) I am going to make a guess that the sheer size of that logging is what ends up breaking the build.
I would chat with some gatsby specific peeps:
to see if they have ideas for you on how to deal with that, as I think that’s where things go awry.
(Not sure if this is applicable to what you need, but, we do also have a nice tool called #netlify-large-media-nlm that makes working with images easier if they are larger, fyi)
I rewrote my code so that the list of pages/urls is only built once, in a react component that is positioned in the Layout component, and now it’s only generating about 3,000 lines of deploy log content. But the log still quits with “992 messages pending”, so the logging service still seems to quit after getting full.
I found the thread that recommended appending “; sleep 120; fail;” commands onto the “gatsby build” command. But that didn’t produce anything new.
From the existing posts, I’m thinking that the current logging service is getting full, and quitting before the issue appears in the deploy process log. So I can’t see my issue, and I’m mystified about how to refactor the code to clear the block.
I’d love any insights. I’ll post the most recent log here.
Actually, I cannot save the log here because it’s too long. The log does not list any errors, just that “Shutting down logging, 992 messages pending”
That is a totally reasonable request!
I had to delete the project, I’m afraid. Per some recommendation I found in the support Boards, I hooked a service called Dependa-bot, which auto-updates dependancies on the Git repo, and creates pull requests. These pull requests, triggered Netlify builds which also failed, and chewed up my remaining free build minutes. At 303 minutes (or so) I just deleted the project.
Shortly after, I discovered Gatsy Cloud offers a service called Gatsy Build, which upon Git repo update, triggers a build there, and then deploys to Netlify. That’s what i currently have set up. And I’d like to keep working with this pipeline.
But I now have a $7 bill from the 3+ minutes of build time consumed by Dependa-bot builds, which failed. I’d like to get that zero’d out, if possible. The build fail issue is cloaked by the logging system failure.
In the future, i’ll configure Netlify to skip the build and just deploy from the repo’s “/public” folder, or just continue to run the build at Gatsby Builds and deploy to Netlify.
Can you point me to someone who can help me with that?
Yup, that seems like a reasonable request. I’ve opened a case in our helpdesk for you to handle that, and we’ll get back to you early next week once we’ve gotten the minutes removed.
