I don't like this. We had this retry mechanism in place for a reason - there were times when our nightly builds would fail simply because of a network blip or backend server outage that would be resolved fairly quickly. This allowed us to survive those tmp outages and were able to run the tests.

I also don't like the fallback - if we are telling it to download the latest, we want the latest. We don't want some other version. We have nightly tests that run on different versions of Istio - if we fallback to some version we aren't expecting, our tests might pass when it otherwise should have failed (because it was supposed to be running with one version, but actually ran with another.).

@jmazzitelli Do you suggest leaving everything, but adding a Github Auth Token?

Adding a GitHub Auth Token if one is available is nice.

I would just like:

(a) Keep the retries - if for some reason the latest release version cannot be obtained from the GitHub API - retry it however many times it was retrying before. Same for any other retries that were done in this script (not sure if there were more?). This helps the use case where a network outage or a GitHub outage is causing the failure - usually, those go away within 30 minutes or so. We don't want our nightly tests to fail because of that. If you want, you could look at the HTTP response code and if it is a special code that indicates rate limiting is causing the failure, then you can fail fast in that case (that would be a nice to have, not required - I don't know if GitHub API returns a special response code that means "rate limited failure").

(b) Don't blindly rely on a fallback version. If for some reason the latest version cannot be determined, the script should fail with a non-zero exit code. We don't want to run with some version that we aren't expecting or is not appropriate.

As long as those two things are in the script, feel free to add whatever is needed - github auth token or whatever