Update openapi-generator-cli.sh

[artheus]

• jq executable is a much cleaner way to get version number
• Using jq and getting releases instead of tags allows us to get latest stable release

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
• Filed the PR against the correct branch: master, 3.4.x, 4.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

Description of the PR

Very simple change, simpler way to get latest release (not pre-relase) in the bash script.

[wing328]

@artheus thanks for the PR.

For me, I need to install jq manually in my Mac (which is pretty easy using brew). Would it be better to check if the jq command has been installed in the machine and throw an error message accordingly?

(currently, there's no check for Python installation either but I hope you see my point providing a friendly message in case jq is not yet installed)

[wing328]

cc @jimschubert

[artheus]

@wing328 Well, should not the change I did on row 23 do this?
I mean "This script requires 'jq' to be installed." feels like a quite ok message. No?

[wing328]

@wing328 Well, should not the change I did on row 23 do this?

Right. Sorry I missed that.

I mean "This script requires 'jq' to be installed." feels like a quite ok message. No?

Looks good to me. At least the user is informed certain package needs to be installed.

[jimschubert]

This change forces users to install jq, which may not be an option.

For example, I'm not able to install jq on our Jenkins machines at work. The change means I'm no longer able to use this script.

Is it possible that we can use the releases change but revert back to python usage?

[jimschubert]

@wing328 ^^

[wing328]

@jimschubert understood but the same argument could apply to python as well (but one may argue Python is "usually" pre-installed in the build)

Ideally neither python or jq is required in the script.

What about maintaing a text file to store the latest version so that no parsing is required? (the drawback is of course the overhead to keep it up-to-date as part of the release process)

(I noticed "jq" was mentioned in the documentation before so I thought it's not a bad idea to use it)

[jimschubert]

@wing328 to that argument, mvn and curl would ideally not be needed ;)

I can remove the dependency on mvn fairly easily, and this might be ideal.

Where would your proposed text file reside? My only concerns with a text file are that literally anything could exist in it, and it would be easy for an automated process to "miss" updating it. By using GitHub's API we can be confident of the response and it's structure. That's not too say I'm against a text file (it does simplify dependencies of this script).

Do you know of any other commands which might simplify down to requiring only curl and bash built-ins?

[wing328]

My only concerns with a text file are that literally anything could exist in it, and it would be easy for an automated process to "miss" updating it.

We do have a release checkout script that can be updated to ensure the text filie contains the latest stable version.

Do you know of any other commands which might simplify down to requiring only curl and bash built-ins?

Not that I know of. To me, the simplest solution is to store the version in the text file.

I may have time to try to implement it tomorrow to see how easy it's

[artheus]

I will test this https://gist.github.com/lukechilds/a83e1d7127b78fef38c2914c4ececc3c

…

On Thu, 7 Feb 2019, 17:04 William Cheng, ***@***.***> wrote: My only concerns with a text file are that literally anything could exist in it, and it would be easy for an automated process to "miss" updating it. We do have a release checkout script that can be updated to ensure the text filie contains the latest stable version. Do you know of any other commands which might simplify down to requiring only curl and bash built-ins? Not that I know of. To me, the simplest solution is to store the version in the text file. I may have time to try to implement it tomorrow to see how easy it's — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2065 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlxwofJCBGAx_tqUJn-ZzUawfEUnpzDks5vLE6rgaJpZM4aj1aj> .