Git clone longer than 180 s

[omrihq]

https://jitpack.io/com/github/omrihq/google-cloud-java/57f23567cb/build.log

Git error. Retrying.
Git error. Git clone took longer than 180 s

[jitpack-io]

Hi,

Is it a big repository? How long does a full clone take normally?

[hypest]

👋 @jitpack-io , we have encountered the same issue (Git error. Retrying. Git error. Git clone took longer than 180 s) with https://jitpack.io/com/github/wordpress-mobile/gutenberg-mobile/9abd4aca67/build.log. In our case, the repo is not big per se, but we have a git submodule which is.

Not sure what's the exact command JitPack is using to clone the repo, and whether it's doing a shallow clone already. Is there a way to configure it to do so if it's not already shallow cloning? Thanks!

[jitpack-io]

Hi,

When JitPack clones a repository it will also update submodules. This is not configurable at the moment but could be a good enhancement. We probably can't make it configurable in yml as that is stored in the repository itself. Is the submodule required for your build?

[hypest]

Thanks for replying @jitpack-io ! 🙇‍♂️

When JitPack clones a repository it will also update submodules

Can you confirm if that checkout is shallow (say, --depth 1) or whether the checkout overrides the shallowness configuration of the submodules (say, by using the --no-recommend-shallow option)?

Although not a solution to the ticket by any means but, I wonder if the build logs could include the commands and outputs from the cloning stage too. It would be very helpful to us while debugging the issue.

For what is worth, here is the PR I introduced to our project to configure the submodules to be shallow by default. We couldn't be sure if it fixed the issue for us though, since we don't know if the cloning commands on JitPack are overriding that configuration, or if the repo is still too large and exceeds the 180secs limit to clone.

This is not configurable at the moment but could be a good enhancement. We probably can't make it configurable in yml as that is stored in the repository itself.

Ah, I see. That makes sense, the yml file is available only after git-cloning anyway, and it's the git-cloning that fails here.

Is the submodule required for your build?

Yes, in our case, the submodules have code that we build and bundle (as an Android asset) to the final library artifact. That code is then used by the library client.

[maxme]

@jitpack-io We found a git flag that makes the cloning process faster (and takes less bandwith): --shallow-submodules, is this something you could add on your side?

The test we did. Without the flag:

$ time git clone -j 12 --depth=1 --recurse-submodules --single-branch --branch develop [email protected]:wordpress-mobile/gutenberg-mobile.git
49.31s user 7.20s system 92% cpu 1:01.26 total
$ du
321Mb

and with the --shallow-submodules flag:


$ time git clone -j 12 --depth=1 --shallow-submodules --recurse-submodules --single-branch --branch develop [email protected]:wordpress-mobile/gutenberg-mobile.git
32.06s user 4.73s system 85% cpu 38.943 total
$ du
148Mb

[jitpack-io]

Hi,

Thank you for the suggestions! We want to improve the cloning process and are looking at various options to make it more configurable.

[alisman]

Did anything become of this?

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.