The original thinking was that it would be quicker to reuse
the existing release mode deps, but I'm not sure if that is
still true, so let's test it to see.
At the time of writing, the test phase takes 8-12 minutes depending
on the OS, with most of that being compilation.
* ci: Use cargo-nextest to improve testing times
* chore: Regenerate workflows
* chore: Use nextest in non generated workflows
* fix(nextest): No fail fast
* fix: Caching of nextest ignores conatiner
* chore: Regenerate workflows
* fix(ci): Wrong input to cargo-install action
* fix: Merge conflicts
* fix(flaky-tests): Try updating OpenSUSE Leap to 15.4
* fix(generate-workflows): Do not use actions-rs
[actions-rs/toolchain](https://github.com/actions-rs/toolchain) is unsupported:
- Has not recieved updates since November 2020 (~2.5 years)
- It uses Node.js 12 and GitHub will stop supporting it Summer this year(?) see
this [article](https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/).
[dtolnay/rust-toolchain](https://github.com/dtolnay/rust-toolchain) is
actively supported and its mostly a 1-1 replacement, the differences are:
- Uses the minimal profile always, so no need to specify it.
- There is no need to override the toolchain.
I also removed some things:
- None of the generated actions use `rustfmt` so I removed the component
- The toolchain is always stable, so I specified it in the action itself
instead of in the action parameters.
* ci: Regenerate workflows
* fix: Remove ALLOW_UNSECURE_COMMANDS from action
* fix(CentOS7): Manually install rustup as CentOS7 uses a very old curl
* fix: Restart shell so that the rustup command is available
* feat: Add exeption to the CentOS workflow to download rustup
* fix: Remove actions-rs/toolchain from remaining workflows
* fix: Address review comment
GH actions has been awful slow and bogged down recently,
getting in the way of work that is more important.
This commit removes a variety of alpine builds (which are
not widely used by wezterm users), and the eldest fedora
version to free up some resources.
dc728b3895 introduced some non-determinism
by mutating the global TARGETS list.
The result is, depending on iteration order, the generated jobs
may inherit the env from earlier jobs.
Notably, if the tag job inherit the schedule reason from a continuous
job, they'll upload assets with an incorrect filename.
This commit restores the determinism by forcing each iteration
of the generation loop to make a deep copy of the statically
defined information in TARGETS.
While we're at it, ensure that the list of env vars is sorted
to avoid non-determinism there as well.
refs: https://github.com/wez/wezterm/issues/2176
We were uploading all the packages as `wezterm-20220419.075038-r0.apk`
regardless of the alpine version.
Also, what we upload to the nightly release must not include a version
number, otherwise the release will hold an unbounded number of versions!
