Deploy fails with "Failed during stage 'preparing repo': exit status 128"

Netlify instance name: friendly-engelbart-5d4042

I have been trying to build a new Gitlab repo that I pushed yesterday and the deploy script always fails to clone the repo:

1:43:23 PM: [feature enabled]: Nitro deploys enabled. Buckle up! ⚡️
1:43:23 PM: Build ready to start
1:43:25 PM: build-image version: 9cade8af58c2cf3a17a1e9433d2e979149488837
1:43:25 PM: build-image tag: v3.3.5
1:43:25 PM: buildbot version: 77379b6d05a07355f28f6b725fb3c96cb742a426
1:43:26 PM: Fetching cached dependencies
1:43:26 PM: Failed to fetch cache, continuing with build
1:43:26 PM: Starting to prepare the repo for build
1:43:27 PM: No cached dependencies found. Cloning fresh repo
1:43:27 PM: git clone git@gitlab.com:XXX/YYY
1:43:28 PM: Error cloning repository: git@gitlab.com:XXX/YYY
1:43:28 PM: Failing build: Failed to prepare repo
1:43:28 PM: failed during stage 'preparing repo': exit status 128
1:43:28 PM: Finished processing build request in 2.295899295s

I tried selecting another repo for the same Netlify instance and everything worked. I even created a new Gitlab repo and the issue still remains. Any ideas?

Deploy ID: 5e5e42db4179721eddf5997d

That repo has a very odd file in it. In our internal logs I see:

error: unable to create file input/Shader Graphs/ἶ1ἶeかもそば ἶ9ἵ8 on Twitter- "Overlayブレンド、 ブレンドかける側とかかる側を入れ替えると結果がだいぶ変わって楽しい...(Overlayブレンドが中で何をやってるのか理….webloc: File name too long

So - I think you can fix that :slight_smile:

Hey there!

That’s interesting!

It looks like this file was correctly commited via Git and can be pushed and pulled to and from my repo without any issues on my local machine (running MacOS), but it does have an issue when the repo is cloned by Netlify.

I noticed that there’s a git config key regarding this issue: https://stackoverflow.com/a/55688377/60949 Is there any way this can be set on the Netlify runner, so that the error is fixed?

If not, is there a way I get this error log, so I can identify which files have a long filename? I think they maybe more than one.

Update: I have renamed two of the files containing Japanese characters on the filename and everything works now. It would be useful if that internal log was exposed to the build deploy log, so that we can have a better understanding of what’s going wrong during cloning.

1 Like

Glad that fixed things for you and that you’re up and running!

And I hear you about wanting more visibility into what’s happening when Netlify clones. The truth is that Netlify does a ton of things behind the scenes to get deploys, repo integrations, forms, functions, and all the things working, and we have to strike a balance between sharing enough of that with you so you know what’s going on vs. not overwhelming people, especially people who are new to our platform or even new to programming in general.

Thank you for your reply Jen!

Yeah, you do have a point about that, given that Netlify’s support is really fast and helpful, I guess there’s no need for more verbose logging at the moment :slight_smile:

1 Like

I’m going to mention this here in case it happens to anyone else.

I have Netlify Large Media installed and I got this error. It turns out that it was because Large Media was set to a different site, which caused the repo pull to fail (I assume because it couldn’t fetch the large media objects).

Might be more of an edge case, but I found this thread looking for answers and thought maybe someone else might want this here.

Hi, @explore. We do cover that scenario in the “Limitations” section of the Large Media documentation here:

https://docs.netlify.com/large-media/requirements-and-limitations/#limitations

Quoting:

  • Files tracked with Netlify Large Media are tied to a specific site. This means that Deploy to Netlify buttons and repositories with multiple connected sites (such as monorepos) are not supported. Similarly, you cannot create a new site from a fork of a repository, though you can fork a Large-Media-enabled repository for the purpose of making contributions to be merged into the original repository.

If there are other questions or concerns, please let us know.

Yes, and specifically this bullet in our case:

  • Files tracked with Large Media are uploaded directly to the Netlify Large Media storage service on push, completely bypassing the site build. This saves build time, but also means that the files are not available to tools that process asset files during the build, such as Hugo’s image processing or the gatsby-image plugin. Depending on your needs, you may be able to replace this functionality with Netlify’s image transformation service.

Thanks for the link, I’m sure that will be helpful.