I have a public repo for a website which is built/served by Netlify as
I regularly fails to fetch the repo (reading other posts I guess the issue is related to the fact git submodule for the hugo theme) but it was not the case till recently AND it always succeeds if I select “Retry deploy” → “Clear cache & deploy site”.
Of course doing this manually for every commit I push, so I am looking for help/hints/suggestions because what I found around here in the Netlifu community did not help.
FYI website repo branch I am working on (the one linked to PR#22) is in synch with the latest commit on master of the theme.
website repo: GitHub - euctrl-pru/portal: The source of PRU Data Portal
working branch: https://github.com/euctrl-pru/portal/tree/202005-release-ace-dashboard
theme repo: Commits · euctrl-pru/pru-theme · GitHub
theme repo latest commit is fbaa99e like the one pointed out by the themes/pru-theme in the website repo pru-theme @ fbaa99e
I have tried the docker image to debug locally, and it works there.
All in all it looks like that if the cache is not cleared the fetching of the relevant pull request from github fails…
Thanks @Pierparker but the commits are ok. In fact clearing the cache and redeployin works!
And I double checked the commits and they are aligned: parent repo branch points to latest of submodule.
So, this isn’t a usual error. I think the reason you don’t see it locally is that the local setup doesn’t try to run what our CI does precisely, since you start from the repo and we’re failing to clone. Here’s exactly why from some internal logs:
Error fetching branch: https://github.com/euctrl-pru/portal pull/22/head: From https://github.com/euctrl-pru/portal
* branch refs/pull/22/head -> FETCH_HEAD
Fetching submodule themes/pru-theme
From https://github.com/euctrl-pru/pru-theme
82184b9..fbaa99e master -> origin/master
fatal: remote error: upload-pack: not our ref 3c7be4357bb827f8f0e0508834931fc48a1f8f59
Errors during submodule fetch:
themes/pru-theme
I don’t know what that means, but maybe you can tell based on the fact that we get it from running:
so perhaps it is something around your .gitmodules config? I bet you could reproduce locally just running that command in a directory that you don’t already have things checked out.
Thank you @fool I will try to reproduce locally.
Strangely it seems NOT to fail when you clear the cache and redeploy…what do your internal logs say for the same clone step when the cache is cleared: each recent failure is followed by a clear cache/redeploy.
On the specific laptop I am now using, I did not have SSH keys set up, so I added them and on my github settings too. I do not think this is the reason of the failure because it has worked in the past and it works if you clear the cache…but I mentioned just to provide complete info.
@fool anything else I could try?
Thanks again for considering all these requests of mine!
Ciao
Hey @espinielli,
If you’re still running into this, I wanted to share this suggestion in a comment on the build-image repo in case you want to give it a shot (i.e., string together the submodule command @fool suggested plus your Hugo build command as one long build command)?
On a separate note, it is surprising to see a missing 4GB cache solve the problem: failed deploy
3:41:09 PM: Fetching cached dependencies
3:41:09 PM: Starting to download cache of 3.9GB
successful deploy
4:25:03 PM: Fetching cached dependencies
4:25:03 PM: Starting to download cache of 254.9KB
