search

oven-sh / setup-bun

Set up your GitHub Actions workflow with a specific version of Bun
MIT License
450 stars 37 forks source link

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

Open byCedric opened 12 months ago

byCedric commented 12 months ago

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:

image

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 using `1.0.x` as version
1.x using `1.x` as version
1.0.11 ✅ - but big image, see below
latest ✅ - but big image, see below
See 1.0.11 response ![using `1.0.11` as version](https://github.com/oven-sh/setup-bun/assets/1203991/89295f33-81ae-4344-a925-3ec47f21d2db)
See latest response ![using `latest` as version](https://github.com/oven-sh/setup-bun/assets/1203991/9db82832-351a-4bd2-818a-51d40b0b32eb)
byCedric commented 12 months ago

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 commented 12 months ago

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

byCedric commented 12 months ago

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

Electroid commented 12 months ago

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

xhyrom commented 8 months ago

Looks like this is already fixed.

na-ji commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

image

Also failing for "1.x"

xhyrom commented 6 months ago

image

Also failing for "1.x"

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

xhyrom commented 6 months ago

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

jerome-benoit commented 6 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 3 months ago

Pull request https://github.com/oven-sh/setup-bun/pull/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)