Version selectors 1.x/1.0.x result in 400/404 response errors on install

[byCedric]

We use bun in various parts of the expo/expo repository, e.g. here. Like the node setup action, we use a version selector with a .x, e.g., node-version: 18.x.

This seemed to work until some days ago when our CI started failing with the following message:

A quick test showed that using the exact version number does seem to work, but 1.x or 1.0.x won't anymore. Is this something that never should have worked, or a bug? 😄

request	response
1.0.x
1.x
1.0.11	✅ - but big image, see below
latest	✅ - but big image, see below

See 1.0.11 response

See latest response

[byCedric]

If this shouldn't have worked from the start, consider adding it 😄 The benefit of bun-version: 1.x over bun-version: 1 is that YAML (& tooling) will cast the value as a string instead of a number.

[xhyrom]

This is an issue with bun's api, sadly, I can't do anything with it. Electorid must solve it.

[byCedric]

I'd figure as much 😄 Thanks for pulling in the right person to solve it.

[Electroid]

We actually think this could be a bug in Bun. These errors are not from Github, we're investigating.

[xhyrom]

Looks like this is already fixed.

[na-ji]

Looks like this is already fixed.

It isn't. It's giving a different error now. When I try 1.x, I get this 404 error:

Run oven-sh/setup-bun@v1
  with:
    bun-version: 1.x
    no-cache: false
Downloading a new version of Bun: https://bun.sh/download/1.x/linux/x64?avx2=true&profile=false
Error: Error: Unexpected HTTP response: 404

I guess we should re-open this issue. And maybe link it to an issue on bun side?

[xhyrom]

Looks like this is already fixed.

It isn't. It's giving a different error now. When I try 1.x, I get this 404 error:

Run oven-sh/setup-bun@v1
  with:
    bun-version: 1.x
    no-cache: false
Downloading a new version of Bun: https://bun.sh/download/1.x/linux/x64?avx2=true&profile=false
Error: Error: Unexpected HTTP response: 404

I guess we should re-open this issue. And maybe link it to an issue on bun side?

I tried it and it works. Maybe you can try again? :D

[Zeryther]

Also failing for "1.x"

[xhyrom]

Also failing for "1.x"

can you send the details please? (click on the first line)
don't have to ;)

[xhyrom]

Something is wrong with bun's download api again. https://github.com/oven-sh/setup-bun/actions/runs/9020175817

[jerome-benoit]

The issue seems triggered each time a bun new version is in the release pipeline: new version seems to be announced to the download system before the pipeline has finished and binaries are available. And fallback to previous matching latest version does not seem to work.

[jerome-benoit]

The issue seems triggered each time a bun new version is in the release pipeline: new version seems to be announced to the download system before the pipeline has finished and binaries are available. And fallback to previous matching latest version does not seem to work.

The error pattern seems more related to a call to an API that is rate limited if the version contains some kind of wildcard. It seems to involve a call to a rate limited API to get a list of the available bun versions which is failing.

[xhyrom]

The issue seems triggered each time a bun new version is in the release pipeline: new version seems to be announced to the download system before the pipeline has finished and binaries are available. And fallback to previous matching latest version does not seem to work.

The error pattern seems more related to a call to an API that is rate limited if the version contains some kind of wildcard. It seems to involve a call to a rate limited API get a list of the available bun versions which is failing.

I'm considering implementing wildcard resolution into the action itself instead of using API for it. It would resolve all the issues we're currently facing.

[jerome-benoit]

I'm considering implementing wildcard resolution into the action itself instead of using API for it. It would resolve all the issues we're currently facing.

With a static file containing all the shipped bun versions like https://nodejs.org/download/release/index.json, it will allow tools like setup-bun to get it, cache it and refresh it only if needed. Adding its generation to the bun release process should not be too hard. Adding a way to get its content hash will help tools at knowing if a refresh is needed.

[Dessyume]

Just ran into this issue on a private repository while using the 1.x selector. I went with Cedric's fix and changed it into latest.

As far as I'm aware, this shouldn't be a hard thing to fix, so let's hope for the best I guess.

[xhyrom]

Pull request #93 should resolve all issues related to this. Anybody can try the development version of setup-bun by using oven-sh/setup-bun@feat/implement-wildcard-resolution-into-the-action (i hope that reference works)

[typed-sigterm]

Not only 1.x, 1 will fail also