Creating a manifest for nextest

taiki-e / install-action

GitHub Action for installing development tools (mainly from GitHub Releases).

Apache License 2.0

249 stars 32 forks source link

Creating a manifest for nextest #487

Closed jayvdb closed 2 months ago

jayvdb commented 3 months ago

nextest is currently a special case found at https://github.com/taiki-e/install-action/pull/473#discussion_r1606066064

It seems reasonable for this popular tool to be supported directly by this action, so binstall doesnt need to be used for it.

Is there anything that needs to be done in order to avoid breaking existing users who are using the "nextest" tool - i.e. switching them from binstall to native manifest installs?

taiki-e commented 3 months ago

See https://github.com/taiki-e/install-action/pull/183 (and PR/issue linked in it) for the context.

It is my experience that installation via binstall is considerably less reliable than the natively supported tools in install-action, when GITHUB_TOKEN is not set, but the netest maintainers preferred it, so I will leave it to them to decide.

jayvdb commented 3 months ago

Interesting! I have been thinking about https://github.com/taiki-e/install-action/issues/488 for a while now, and had starting writing it up.

IMO we should address the yanking problem, but the needs of the user are more important.

taiki-e commented 3 months ago

IMO we should address the yanking problem

yanking is already respected (https://github.com/taiki-e/install-action/pull/180), However, it will not be reflected immediately, but will be reflected with a slight delay, just like a normal update. We could make it reflect immediately (see https://github.com/taiki-e/install-action/pull/182), but that would also be a way to burden crates-io's servers.

sunshowers commented 3 months ago

Hi!

(Thanks as always for maintaining this action, Taiki!)

The main challenge for me really has been yanking. There was an issue a while ago where there was a nextest version that was breaking a ton of setups -- I could yank it within minutes, but it was broken for a number of hours.

Some alternatives managed by us are:

The URLs as defined in https://nexte.st/book/release-urls (I believe we used to use these originally) -- e.g. https://get.nexte.st/0.9/x86_64-unknown-linux-gnu
The JSON file at https://get.nexte.st/releases.json, contains both URLs and yank information.

Those are both the ultimate source of truth for the latest version, and are hosted at Cloudflare. Would it make sense to use either of these, or maybe some other format that is convenient? (Happy to provide e.g. a URL which just tells you whether a version is yanked if that makes sense!)

jayvdb commented 3 months ago

Those would still be a special case only for nextest. IMO the solution at https://github.com/taiki-e/install-action/pull/182 , an install time / runtime check of yanked crates, should suffice, and that fixes the yanking problem for all crates, not just nextest.

sunshowers commented 3 months ago

Sure! Just wanted to provide an alternative in case #182 is unfeasible.

taiki-e commented 2 months ago

Filed #518 to revert #183 and reinstate #182.

The URLs as defined in https://nexte.st/book/release-urls (I believe we used to use these originally)

This was incompatible with the checksum, so we were switched to the GH release.