Creating a manifest for nextest

[jayvdb]

nextest is currently a special case found at #473 (comment)

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]

See #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]

Interesting! I have been thinking about #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]

IMO we should address the yanking problem

yanking is already respected (#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 #182), but that would also be a way to burden crates-io's servers.

[sunshowers]

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]

Those would still be a special case only for nextest. IMO the solution at #182 , an install time / runtime check of yanked crates, should suffice, and that fixes the yanking problem for all crates, not just nextest.

[sunshowers]

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

[taiki-e]

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.