Keep 3 days of nightlies

[onbjerg]

Cleans up the release workflow a bit and keeps 3 nightlies.

Nightlies are now tagged with nightly-$SHA as well as nightly. To find the latest nightly, you would look up the nightly tag and find the release at nightly-$SHA where $SHA is the commit that nightly is pointing to.

The workflow only deletes releases that have nightly in the tag of the release, which allows us to release other pre-release versions (betas etc.)

This also adjusts foundryup accordingly and there is a PR for foundry-toolchain too: foundry-rs/foundry-toolchain#2. This is a breaking change for foundryup.

Closes #472

[onbjerg]

Waiting for #488 to adjust foundryup so we avoid merge conflicts

[onbjerg]

I think we need a better construct for release channels. For nightly the setup in this PR works fine, but for stable it does not: the primary tag of the release is not a stable-$SHA tag, it's a vx.y.z tag. I looked at GitHub's API and there is no way for us to get all tags pointing to a specific commit unless we literally just iterate over all tags in the repository (worst case).

An alternative would be to have some file that just describes the latest release in each channel like:

nightly: nightly-$SHA
stable: v1.0.2

Note that it is not a JSON file or something similar: it is easy to parse in both Node.js (for the action) and Bash (for foundryup). The question is where to host this file.

[onbjerg]

foundryup now handles channels (currently only nightly, see above for reasoning). Running foundryup -v nightly will resolve the tag using GitHub's API and download the correct release after this PR is merged.

We should release a new nightly ASAP when this is merged, otherwise installations will fail

[transmissions11]

need to use the new foundry paradigm link in the foundryup dir's readme as well :)

[onbjerg]

Let me know when you think this is mergeable @gakonst and we can coordinate (need to release the GHA update around the same time)

[onbjerg]

Anything blocking this when rebased? @gakonst

[gakonst]

Can we simplify this using the new forge version which shows the commit? Cc @mattsse

[onbjerg]

The tags can't really be simplified due to how GitHub releases work, at least not without some secondary release channel to keep track of what the latest nightly is :/

The bulk of the complexity in here is figuring out what the latest pre-release is. GitHub has a redirect to the latest non-pre-release version but not one for prereleases

Actually, looking at it, the redirect is for the latest release overall, so this complexity is going to be needed for stable releases instead (as pre-releases would show up as the latest release)

[gakonst]

OK defer to you on it, let's just refactor the inline js to scripts under .github?

[onbjerg]

The only alternative I would know of is to have an actual channel file that gives us the latest tag for each release channel, e.g.

stable: v1.2.3
nightly: nightly-abcdefg1234

And then you would parse that. Just requires either (1) a place to store the file, where we can also modify it from this workflow or (2) that we commit that file directly to this repository from this workflow

[gakonst]

ok let's see how this goes