Try previous version on download fail
Closed this issue · 5 comments
Is your feature request related to a problem? Please describe.
Not a problem, an improvement in case of failure.
Terraform 1.2.6 just got released but hashicorp's link is not working resulting in a fail when doing something like this:
$ tfswitch -s 1.2.0
Matched version: 1.2.6
Downloading to: /root/.terraform.versions
[Error] : Unable to download from https://releases.hashicorp.com/terraform/1.2.6/terraform_1.2.6_linux_amd64.zip
Describe the solution you'd like
tfswitch trying to get the previous version, maybe with an optional switch
Additional context
We use tfswitch in our deployment pipeline but this external fail makes all job fail. Not really tfswitch's fault, but there could be a "DR" options :)
Why did this particular download fail? I'd rather implement retries of the same version vs falling back.
Why did this particular download fail? I'd rather implement retries of the same version vs falling back.
It failed because hashicorp's link was 404-ing, retry would not have solved it and it took about 2h for them to fix the download link.
It was also broken on their own website.
Only the latest version (1.2.6) was broken (installed using --latest-stable=1.2.0), 1.2.5 download link was still working fine
Incident:
https://status.hashicorp.com/incidents/1jw0q79c6cd5
I'd support what @jukie said: we should not attempt to workaround Hashicorp's infrastructure malfunction (or any other kind of failures which are not specific to tfswtich) as they are external dependency not only for tfswitch and are not meant to be in place at all (as in should be fixed asap).
As for CI/CD I'd suggest you to make it more reliable and durable by adopting "repeatable builds" approach, which implies automation doesn't bump version of software until it is fully tested and verified by engineers. IMHO.
I would have assumed that using tfswitch with the --latest-stable would not render a un-usable product hence the suggestion to try the previous stable version in these scenario since we're assuming that --latest-stable will provide with a usable binary, and avoid having to build our own logic to validate the --latest-stable actually provided a usable binary.
We can add some logic to make sure something was downloaded but doing that would also raise the question of why using an external dependency (tfswitch) if we need to check that it did what was expected. This options doesn't specify a version, we expect tfswitch to provide the latest stable, 1.2.6 was "unavailable" at this point, 1.2.5 was then the latest stable.
Since this doesn't seems like it's going to be added, you can close this issue.
we expect tfswitch to provide the latest stable, 1.2.6 was "unavailable" at this point, 1.2.5 was then the latest stable.
1.2.6 was latest stable at that moment and 1.2.5 was one before latest stable. This is important.
It was not available due to the external to tfswitch reason, which could had been not just a broken download link on Hashicorp site with releases, but also a network blip, or destination being blocked somewhere in the midway, or a source being blocked on destination, whatever. Falling back to previous not latest version in such use cases would end up with an unexpected behavior and result and would contradict to what the meaning of this parameter is.
Since this doesn't seems like it's going to be added, you can close this issue.
👍🏻