-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Git clone is failing when blobs filter is unavailable on platform #13440
Comments
You can enable it in gitea. |
Thank you, now I see. So, maybe log this link for this particular stack trace? |
You need this in
Are you using the official docker image? |
No, I've just tried to run with their public test instance. |
🤔 For me it works even without the upload filter, but it will do a full clone then automatically. Maybe they have some extra filtering on the test instance? |
Possible ways to fix are:
|
I'm having the same issue as @zharinov using the gitea official docker image (git version 2.30.2) without explicitly disabling clone filters (so enabled by default). Adding |
This might've changed on Gitea side very recently. v1.15 should work as @viceice mentioned (no configuration necessary) while v1.16-rc1 requires explicitly enabling The reason this happens on test instance is because they always use newest development version there. Possibly introduced by go-gitea/gitea#18195 but without doing full bisect it's going to be hard to debug, they've been doing lot of changes near internals on how they handle Git commands overall.
|
That pr explicit enables filters, so it should just work. Are you using the official docker image? As the filter only work with git 2.22+. See PR changes. |
Using Both meet requirements: # docker run -ti ***/renovate sh
$ git --version
git version 2.35.0
# docker exec -ti gitea sh
$ git --version
git version 2.30.2
Indeed, it should - yet it doesn't, unless [uploadpack]
allowfilter = true is added to Root cause analysis
It used to work on previous development snapshot of v1.16 and I can pinpoint it to specific and and hour:
The time matches when Gitea was upgraded to Immediately after upgrade it started failing for these with:
As such, I believe that the issue has been indirectly introduced by previously mentioned commit - it tries to enable the functionality by default, however by doing so it trips on by failing to properly construct valid parameters for git command as explained on go-gitea/gitea#18373 Unsure at the moment if there's anything that Renovate should do on its side. This will be fixed soon on Gitea side and the fix will be included in official 1.16 release version. Renovate is trying its best to act as it should and as far as I understand the issue at the moment, it's a server (Gitea in this case) that is acting incorrectly by failing a valid request. |
I didn't see any issues with official v1.16 docker image. (Rootless) |
Correct @viceice, go-gitea/gitea@42991dc is commit that fixes it for 1.16 branch (backport of go-gitea/gitea#18373). Only |
How are you running Renovate?
Self-hosted
If you're self-hosting Renovate, tell us what version of Renovate you run.
Latest
Please select which platform you are using if self-hosting.
Gitea
If you're self-hosting Renovate, tell us what version of the platform you run.
Latest
Describe the bug
Gitea doesn't support shallow clone yet, which causes our our HTTPS authenticated clone to fail.
Relevant debug logs
Logs
Have you created a minimal reproduction repository?
https://try.gitea.io/zharinov/shallow-test
The text was updated successfully, but these errors were encountered: