Skip to content
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

Gitea fails to start with git 2.29.0.rc0.261.g7178c9af9c #13067

Closed
2 tasks done
wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf opened this issue Oct 7, 2020 · 12 comments · Fixed by #13169
Closed
2 tasks done
Assignees
Labels
type/bug type/upstream This is an issue in one of Gitea's dependencies and should be reported there

Comments

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf
Copy link
Contributor

Oct 07 19:24:10 nebula gitea[27964]: 2020/10/07 19:24:10 cmd/web.go:108:runWeb() [I] Starting Gitea on PID: 27964
Oct 07 19:24:10 nebula gitea[27964]: 2020/10/07 19:24:10 ...s/setting/setting.go:804:NewContext() [I] Default UI Location is Europe/Vienna
Oct 07 19:24:10 nebula gitea[27964]: 2020/10/07 19:24:10 ...dules/setting/git.go:68:newGit() [F] Failed to initialize Git settings%!(EXTRA *log.ColoredValue=Git version missing: Malformed version: 2.29.0.rc0.261.g7178c9af9c)
Oct 07 19:24:10 nebula systemd[1]: gitea.service: Main process exited, code=exited, status=1/FAILURE

Description

Gitea fails to start after a recent update, I suppose the reason might be an error in parsing of the git version string, as it recently moved on to an rc for 2.29.0 (see git version above) and changed the format a little - note the added rc0.
A rollback to an earlier version of git (git version 2.28.0.788.g542b3c2573 - which has been working just fine before) as well as to a previous release version (such as 2.28.0) solves this for me momentarily and Gitea starts without issues.

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf
Copy link
Contributor Author

Also, we have already seen something similar in #12731 before.

@6543 6543 self-assigned this Oct 7, 2020
@lunny lunny added the type/upstream This is an issue in one of Gitea's dependencies and should be reported there label Oct 8, 2020
@6543 6543 removed their assignment Oct 13, 2020
@6543
Copy link
Member

6543 commented Oct 13, 2020

I tryed to enhance the regex again, didnt found a good soultion for now :(

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf
Copy link
Contributor Author

I tryed to enhance the regex again, didnt found a good soultion for now :(

I'm trying something, too.

@eneuschild
Copy link
Contributor

Please ignore that PR from me for this issue. Some autocomplete feature ran amok and linked the wrong issue.

Sorry for the confusion. :-|

@eneuschild
Copy link
Contributor

... but now that I'm here, I might as well look into the issue.

I did some tweaking of the RegEx myself and actually quickly found one that worked.
But: the upstream project insists that versions validated with it follow SemVer, which, unfortunately, 2.29.0.rc0.261.g7178c9af9c doesn't.

SemVer demands the following:

<valid semver> ::= <version core>
                 | <version core> "-" <pre-release>
                 | <version core> "+" <build>
                 | <version core> "-" <pre-release> "+" <build>

<version core> ::= <major> "." <minor> "." <patch>

In prose: the version core, in the case of our offending git version 2.29.0, must be followed by either a + or a -.

What we have instead is a ..

In conclusion, as long as gitea uses hashicorp/go-version with its demand for correct Semantic Versioning, I don't see how it can support git version 2.29.0.rc0.261.g7178c9af9c. So we can

  • either look for different version parsing
  • or declare this a "Won't Fix".

@6543
Copy link
Member

6543 commented Oct 15, 2020

@eneuschild go-version has two functions ... one who explicit only parse SemVers and one who try to parse Versions at all (second one is used and should know what to do with the string ...)

PS: until hashicorp do not act at all, can you send pulls to my fork & upstream?

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf
Copy link
Contributor Author

... but now that I'm here, I might as well look into the issue.

I did some tweaking of the RegEx myself and actually quickly found one that worked.
But: the upstream project insists that versions validated with it follow SemVer, which, unfortunately, 2.29.0.rc0.261.g7178c9af9c doesn't.

SemVer demands the following:

<valid semver> ::= <version core>
                 | <version core> "-" <pre-release>
                 | <version core> "+" <build>
                 | <version core> "-" <pre-release> "+" <build>

<version core> ::= <major> "." <minor> "." <patch>

In prose: the version core, in the case of our offending git version 2.29.0, must be followed by either a + or a -.

What we have instead is a ..

In conclusion, as long as gitea uses hashicorp/go-version with its demand for correct Semantic Versioning, I don't see how it can support git version 2.29.0.rc0.261.g7178c9af9c. So we can

  • either look for different version parsing
  • or declare this a "Won't Fix".

whoa, this was fast!
well that is bad news, really, at least until git moves from rc to regular dev (semver compatible) version naming.
I don't see into as to why they opted for the current one, but I'd vouch for rather following whatever git folks are doing than rigidly proper semver - as that may in turn leave us with Gitea failing to start for users with git present on the system - be it a pre-release version - and the error saying it's not present.

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf
Copy link
Contributor Author

Or we should advise users not to use pre-release git because of the above mentioned issue (possibly until it's resolved, either on our side or upstream)..

@eneuschild
Copy link
Contributor

@eneuschild go-version has two functions ... one who explicit only parse SemVers and one who try to parse Versions at all (second one is used and should know what to do with the string ...)

PS: until hashicorp do not act at all, can you send pulls to my fork & upstream?

On it. :)

@6543
Copy link
Member

6543 commented Oct 16, 2020

ok first pull got merged, waiting for second one ... will release new version after this :)

@6543
Copy link
Member

6543 commented Oct 16, 2020

-> #13169

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf
Copy link
Contributor Author

-> #13169

works like a charm, thanks! @6543 @eneuschild 🎉

@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/bug type/upstream This is an issue in one of Gitea's dependencies and should be reported there
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants