Bug: tea command fails when remote version is a SHA1 #531

New Issue

ideasman42 · 2023-02-08T23:13:03Z

ideasman42 commented

2023-02-08 23:13:03 +00:00

describe your environment

tea version used (tea -v): 0.9.0-1
- I also reproduced the issue: Version: 0.9.0+11-gfaa9858 golang: 1.20 go-sdk: v0.15.1-0.20220927025037-8f846bdb9bbe
Gitea version used:
- the issue only occurred after updating gitea recently
operating system:
I make use of...
- non-standard default branch names (no main,master, or trunk)
- .ssh/config or .gitconfig host aliases in my git remotes
- ssh_agent or similar
- non-standard ports for gitea and/or ssh
- something else that's likely to interact badly with tea: ...

describe the issue (observed vs expected behaviour)

The tea command fails when when the version is a SHA1, I assume this is the remote version as it is a SHA1 from gitea it's self (which I don't have installed).

See: https://github.com/go-gitea/gitea/commit/f63af34

Note, that I've replaced some text with (X), the last line shows the problem

 > tea login add
? URL of Gitea instance:  https://projects.blender.org
? Name of new Login [projects.blender.org]:  
? Login with:  ssh-key/certificate
? SSH Key/Certificate Path (leave empty for auto-discovery in ~/.ssh and ssh-agent): 
? Select ssh-key:  SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ssh-XXX XXX@XXX (/home/XXX/.ssh/XXX.pub)
? Set Optional settings:  No
? ssh-key is encrypted please enter the passphrase:  ***************
2023/02/09 10:01:25 Malformed version: f63af34

### describe your environment - tea version used (`tea -v`): 0.9.0-1 - [x] I also reproduced the issue: `Version: 0.9.0+11-gfaa9858 golang: 1.20 go-sdk: v0.15.1-0.20220927025037-8f846bdb9bbe` - Gitea version used: - [ ] the issue only occurred after updating gitea recently - operating system: - I make use of... - [ ] non-standard default branch names (no `main`,`master`, or `trunk`) - [ ] .ssh/config or .gitconfig host aliases in my git remotes - [ ] ssh_agent or similar - [ ] non-standard ports for gitea and/or ssh - [ ] something else that's likely to interact badly with tea: ... ### describe the issue (observed vs expected behaviour) The tea command fails when when the `version` is a SHA1, I assume this is the remote version as it is a SHA1 from gitea it's self (which I don't have installed). See: https://github.com/go-gitea/gitea/commit/f63af34 Note, that I've replaced some text with (`X`), the last line shows the problem ``` > tea login add ? URL of Gitea instance: https://projects.blender.org ? Name of new Login [projects.blender.org]: ? Login with: ssh-key/certificate ? SSH Key/Certificate Path (leave empty for auto-discovery in ~/.ssh and ssh-agent): ? Select ssh-key: SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ssh-XXX XXX@XXX (/home/XXX/.ssh/XXX.pub) ? Set Optional settings: No ? ssh-key is encrypted please enter the passphrase: *************** 2023/02/09 10:01:25 Malformed version: f63af34 ```

ideasman42 added the

kind/bug

label 2023-02-08 23:13:03 +00:00

techknowlogick commented

2023-02-09 02:09:08 +00:00

Thank you for this report <3

I believe the error is surfaced from the go-sdk due it attempting to parse the version for feature detection.

Right now, it's just failing out, but I wonder if the appropriate action to take would be to assume the lowest version that go-sdk supports in this case. The downside of this is you don't get all of the goodness from the latest APIs, but at least you'd still get a mostly useful experience.

Thank you for this report <3 I believe the error is surfaced from the go-sdk due it attempting to parse the version for feature detection. Right now, it's just failing out, but I wonder if the appropriate action to take would be to assume the lowest version that go-sdk supports in this case. The downside of this is you don't get all of the goodness from the latest APIs, but at least you'd still get a mostly useful experience.

ideasman42 commented

2023-02-09 02:49:40 +00:00

Regarding using the lowest version - I'm not sure what this means in practical terms, but working (even on a basic level) would be a good start :)

jolheiser referenced this issue from gitea/go-sdk

2023-02-09 04:09:26 +00:00

Set client version to lowest for compat if server version can't be recognized #612

jolheiser commented

2023-02-09 04:11:52 +00:00

Possible first step is over at gitea/go-sdk#612

drsybren commented

2023-02-10 10:20:26 +00:00

The solution here might actually be for Gitea itself to provide more info about its version. Just the hash doesn't mean anything; a command like git describe can give the latest tagged version + the number of commits since then. Such info could be deconstructed at compile time, and returned by the API as backward-compatible info:

{
  "version": "a8c6cbf",
  "description": "v1.19.0-dev-525"
}

The solution here might actually be for Gitea itself to provide more info about its version. Just the hash doesn't mean anything; a command like `git describe` can give the latest tagged version + the number of commits since then. Such info could be deconstructed at compile time, and returned by the API as backward-compatible info: ```json { "version": "a8c6cbf", "description": "v1.19.0-dev-525" } ```

jolheiser commented

2023-02-10 13:38:35 +00:00

Generally the binary does embed better information using describe, so I assumed this was a specially built binary.

Since the Gitea version is set with a build flag, technically anyone could set it to anything.

If the binary isn't actually setting the version correctly, then that may be a bug for the main repo.

Generally the binary does embed better information using describe, so I assumed this was a specially built binary. Since the Gitea version is set with a build flag, technically anyone could set it to anything. If the binary isn't actually setting the version correctly, then that may be a bug for the main repo.

drsybren commented

2023-02-10 13:58:55 +00:00

It might be our local build. I just found that if you clone our fork (https://github.com/blender/gitea) you don't get any tags. That explains the lack of more detailed versioning info in the API response.

Update: This issue with our build is now tracked at https://projects.blender.org/infrastructure/blender-projects-platform/issues/22

It might be our local build. I just found that if you clone our fork (https://github.com/blender/gitea) you don't get any tags. That explains the lack of more detailed versioning info in the API response. Update: This issue with our build is now tracked at https://projects.blender.org/infrastructure/blender-projects-platform/issues/22

6543 added this to the v0.10.0 milestone 2023-04-02 21:17:54 +00:00

6543 referenced this issue from a commit

2023-04-02 21:30:54 +00:00

Set client version to lowest for compat if server version can't be recognized and return specific error (#612)

6543 commented

2023-04-02 21:44:27 +00:00

@ideasman42

there is a version_check field for logins in the tea config ... just set it to true

@ideasman42 there is a `version_check` field for logins in the tea config ... just set it to `true`

6543 referenced this issue

2023-04-02 21:49:03 +00:00

if gitea version is not detected, just fall back to last supported one and print warning #538