On the plus-side, it's shorter. On the "minus-side" I couldn't test it. 😅

Thank you for addressing the issue. I would really like to test it before blindly merging it. 😅 And it also should be possible to do so by manually triggering the workflow on a non-tagged version. Maybe we would have to temporarily update the on: value to do so. But we should be able to run it. It's just Upload release archive which should fail then but everything before that should, i.e. building, should work anywhere. Maybe some small other adjustments would be necessary.

If you don't find the time to do so, you can let me know and I'll try do it. It's just that I don't want to debug the workflow during the next release but before merging this PR.

After rebasing onto master, I noticed that the goal of this PR has already been achieved: the current master already has a unified build-release matrix job covering Linux, macOS, and Windows in a single job. I believe we should be closing this as superseded. Thoughts?

Will close for now. I don't think there's anything that needs to be done here. As mentioned, we already have a matrix job.

Erm, sorry, diffed against the wrong branch. This wasn't fixed in master yet. Reopening.

OK, this should be good to go. Thanks, Thomas for the suggestion to run a "test release."

This way, I uncovered an issue with our new file-limits support (#2106).

On Windows, I got

error[E0432]: unresolved imports `rlimit::Resource`, `rlimit::getrlimit`
   --> lychee-bin\src\main.rs:143:18
    |
143 |     use rlimit::{Resource, getrlimit, increase_nofile_limit};
    |                  ^^^^^^^^  ^^^^^^^^^ no `getrlimit` in the root
    |                  |
    |                  no `Resource` in the root
For more information about this error, try `rustc --explain E0432`.
error: could not compile `lychee` (bin "lychee") due to 1 previous error
Caused by:
  process didn't exit successfully:

Inside the rlimit crate, increase_nofile_limit(u64::MAX) evaluates internally via #[cfg(unix)] to attempt bumping to the max hard limit. If it fails, it still gracefully returns Ok(current_soft_limit). And on Windows, via #[cfg(windows)], it simply returns Ok(lim). Source code here.

This means rlimit is already entirely cross-platform and already provides the exact fallback semantics we want internally! The entire limit_result match statement with cfg(unix) and cfg(not(unix)) was just redundant boilerplate. :)

This run shows that all binaries build successfully: https://github.com/lycheeverse/lychee/actions/runs/23962659010/job/69895885187

actions/upload-release-asset@v1 is deprecated and relies on older, outdated versions of Node.js. The gh CLI tool is natively pre-installed on all GitHub-hosted runners (Ubuntu, macOS, and Windows). This makes it universally available without needing to download external dependencies or rely on third-party actions.

Failing test is the flaky WayBackMachine test again...

Failing test is the flaky WayBackMachine test again...

@katrinafyi Addressed this in 434ae96 :)

Thanks again for the PR, I'll test this with the new release

Seems to have worked! 🎉
Now it's just the docker step failing. It's no news that this is unstable but now it fails even after multiple retries.
I'll investigate this as part of #2037 and hope to come up with a stable long-term solution. I feel like docker releases were unreliable since a very long time.