When following https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-linux.html to download and install for linux it appears you get whatever version is current. It would be nice if there was the ability to download and validate a version of the of the CLI, like v2.0.0 or v2.0.1. This would mean changing:
https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip
to something like
https://awscli.amazonaws.com/awscli-exe-v2.0.1-linux-x86_64.zip
and providing corresponding *.sig
files at those same locations for gpg verification.
Hi @chrisgilmerproj,
Yea, there is no instructions on how to get previous versions.
For V1, there is always pip install versioning, but it's not an option for v2 at the moment, I'll mark this as a feature request, and hopefully we'll have a solution for it soon.
@KaibaLopez - I appreciate it and I'll keep my eyes out. We definitely want to start supporting v2 in our infrastructure and versioning will definitely help with repeatable results.
This is a huge issue for package management like Chocolatey/Homebrew/Debian unless they copy a release and hopefully a checksum from somewhere as they are created, as the current publishing mechanism is clobbering old versions and breaking any automations that had a specific checksum saved to avoid man in the middle attacks.
Since working with package managers is apparently a goal of this project, publishing specific versions in the package name and the checksum is imperative.
https://github.com/aws/aws-cli/issues/4947#issuecomment-586046886
@chrisgilmerproj This is a good callout for a documentation enhancement. For both AWS CLI V1 and V2 all artifacts we publish are versioned and previous versions are available in the same locations with the version appended before the extension like so: Artifact-X.Y.Z.ext
.
For AWS CLI V2 the URLs are formatted like so:
https://awscli.amazonaws.com/AWSCLIV2-2.X.Y.msi
https://awscli.amazonaws.com/AWSCLIV2-2.X.Y.pkg
https://awscli.amazonaws.com/awscli-exe-linux-x86_64-2.X.Y.zip
https://awscli.amazonaws.com/awscli-exe-linux-x86_64-2.X.Y.zip.sig
For example v2.0.0 on linux the links would be:
https://awscli.amazonaws.com/awscli-exe-linux-x86_64-2.0.0.zip
https://awscli.amazonaws.com/awscli-exe-linux-x86_64-2.0.0.zip.sig
For AWS CLI V1 the URLs for the bundled installer are formatted:
https://s3.amazonaws.com/aws-cli/awscli-bundle-1.X.Y.zip
@joguSD - This may be exactly what I'm after! I'll give this a shot later. But yes, a documentation improvement would be excellent.
@joguSD - I've got two different repos showing that this works. Would you like me to close this? Or do you want to keep it open until documentation is updated?
@chrisgilmerproj Let's keep it open for visibility reasons until the docs get updated.
Are the docs open source too? Those direct version URLs work for me as well. If someone can point me to the docs I can submit a PR.
Otherwise thanks @joguSD for providing those URLs.
@felicianotech
Yes, you can submit a PR through:
https://github.com/awsdocs/aws-cli-user-guide
Thanks, the docs PR has been opened: https://github.com/awsdocs/aws-cli-user-guide/pull/29
Consider something like this https://updates.jenkins-ci.org/download/war/
@damon-atkins the problem is that requires parsing the page for the checksums, it might be easier to include file-version.extension.SHA256 and .SHA512 files so that you can just append the checksum type you want to the name and not have to scrape a page that will only grow larger with more versions.
The other downside of the Jenkins model is that for the actual download URL it changes a chunk in the middle of the URL every time, rather than having a fully consistent base where only the file name you are grabbing changes and you can easily created a sorted list to find the latest by using JSON from an API.
I'd much rather see by the file name exactly what version I'm downloading and rename it myself if I need a consistent name for automation curl -L https://awscli.amazonaws.com/AWSCLIV2-2.X.Y.msi -o awscliv2.msi
rather than having to pull out a portion of the URL to inject into the name if I wanted to keep a history version or a local cache in case I need to roll back. MY_VERSION=2.X.Y; curl -L https://awscli.amazonaws.com/$MY_VERSION/AWSCLIV2.msi -o awscliv2-$MYVERSION.msi
.
Hi @dragon788 s3 bucket does not lend it self to a list of software versions available.
It could be just a simple text file with a list of available versions, or html file with links, both are easy to parase. With the gpg signature (.sig) the checksum should not be needed. Just a file with a list of versions maybe both text and html format.
+1 for improving the docs. Thanks. The ability to install a specific version is extremely important, rather than always pulling the latest.
Hi all, it looks like this change has been made to the documentation. Thanks again for your comments!
Most helpful comment
@chrisgilmerproj This is a good callout for a documentation enhancement. For both AWS CLI V1 and V2 all artifacts we publish are versioned and previous versions are available in the same locations with the version appended before the extension like so:
Artifact-X.Y.Z.ext
.For AWS CLI V2 the URLs are formatted like so:
For example v2.0.0 on linux the links would be:
https://awscli.amazonaws.com/awscli-exe-linux-x86_64-2.0.0.zip
https://awscli.amazonaws.com/awscli-exe-linux-x86_64-2.0.0.zip.sig
For AWS CLI V1 the URLs for the bundled installer are formatted: