Incompatibility with Gerrit <= v2.14
See original GitHub issueWhen using the Java client with Gerrit v2.14 (or earlier) the ChangeApiRestClient.get() would cause Gerrit to fail with the following error: com.urswolfer.gerrit.client.rest.http.HttpStatusException: Request not successful. Message: Bad Request. Status-Code: 400. Content: "TRACKING_IDS" is not a valid value for "-o".
.
This is causing the Gerrit Code Review plugin for Jenkins to fail (see reported Issue JENKINS-60364).
Issue Analytics
- State:
- Created 4 years ago
- Comments:11 (11 by maintainers)
Top Results From Across the Web
Gerrit 2.14 Release
Gerrit 2.14 introduces a new secondary index for groups. ... It is no longer possible to run Gerrit on JRE 7 and it...
Read more >Gerrit Code Review - Gerrit 2.14 - Google Git
Gerrit 2.14 introduces a new secondary index for groups. ... to run Gerrit on JRE 7 and it is not compatible with JRE...
Read more >Gerrit v2.14 brings new features and UX - GerritForge Blog
It was previously a strongly recommended option, but both Java 7 and 8 were equally supported. The switch to Java 8 comes with...
Read more >Environment variables not being set when Gerrit 2.14
I am trying to downgrade for the time being the Gerrit REST API java layer, so that compatibility with Gerrit v2.14 is resumed....
Read more >[JENKINS-60364] Environment variables not being set when Gerrit ...
I tried with GerritHub (latest version of Gerrit) and it seems to be ... the Gerrit REST API java layer, so that compatibility...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I was thinking about exposing the list of supported options for the current detected version of the server that the client is connected to. Then, even after knowing them, if the client is explicitly using an unsupported option, he will get an exception, which is expected.
If no options are passed, the client will get all the possible options supported by the remote Gerrit server version.
Hope that would make sense.
Thanks @uwolfer for your help in getting this merged and released 😃