Describe the bug The latest (currently 1.7) jq from the URL "https://github.com/jqlang/jq/releases/latest/download/jq-linux64" does not install. (status:404) Until yesterday the latest 1.6 was downloaded.

Oh, interesting. I don't know how to make latest work. Any ideas?

This does work, of course: https://github.com/jqlang/jq/releases/download/jq-1.7/jq-linux-amd64

EDIT: Ah, this link works https://github.com/jqlang/jq/releases/latest/download/jq-linux-arm64

The issue is that we didn't keep the asset name jq-linux64. We didn't because we now produce executables for Linux on more ISAs.

We could restore the jq-linux64 name for backwards compatibility with things that expected that name so they could download jq, but we'd have to do a new version release for that.

Can you update your docker files or scripts to use https://github.com/jqlang/jq/releases/latest/download/jq-linux-arm64 ?

Similar issue. We are using the circleci jq orb circleci/[email protected] and using it to install the latest version of jq.
This tries to get the latest version https://github.com/stedolan/jq/releases/download/jq-1.7/jq-linux64 and then redirected to https://github.com/jqlang/jq/releases/download/jq-1.7/jq-linux64 but returns 404.

The circleci JQ orb needs to be updated as well

I've also encountered an error while using a different library.
(https://github.com/stefanprodan/kube-tools/blob/master/src/install.sh)
Is there any way to keep the previous URL?

I think I'd have to redo the 1.7 release to do what you're asking for, or else do a 1.7.1 release.

I added a jq-linux64 asset that' a copy of the jq-linux-amd64 asset.

I've added

• jq-linux32 as the same as jq-linux-i386
• jq-linux64 as the same as jq-linux-amd64
• jq-osx-amd64 as the same as jq-macox-amd64
• jq-win32.exe as the same as jq-windows-i386.exe
• jq-win64.exe as the same as jq-windows-amd64.exe

and I've

• updated sha256sum.txt accordingly.

I've not yet fixed the GitHub Actions CI workflows to do the same. Maybe that should be a separate issue and for the next release.

@nicowilliams
Thank you for your prompt response.

I strongly recommend to migrate to the new URLs with explicit architecture in executable names, because we may not fix this in the next release.