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
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
checkout seems to be failing for ubuntu 20 recently:
```
Deleting the contents of '/__w/wezterm/wezterm'
Initializing the repository
/usr/bin/git init /__w/wezterm/wezterm
Initialized empty Git repository in /__w/wezterm/wezterm/.git/
/usr/bin/git remote add origin https://github.com/wez/wezterm
Error: fatal: unsafe repository ('/__w/wezterm/wezterm' is owned by someone else)
To add an exception for this directory, call:
git config --global --add safe.directory /__w/wezterm/wezterm
Error: The process '/usr/bin/git' failed with exit code 128
```
Try reverting this as a workaround.
I lost a few hours over the weekend because the GH release uploads
are flakey and the action I was using doesn't internally perform
retries. I had to manually delete the failed uploads from the release
and then re-trigger the builds across several platforms, several times
for both of the releases I pushed this weekend :-/
This commit speculatively switches over to using the GH cli in the
hopes that the error reporting is better, and also because it is
simpler to externally drive a retry loop.
Let's see how this goes.
This commit reduces the cron schedule for nightly builds down from
hourly and to actually nightly (at ~3am).
The push-to-master flow now triggers effectively the same thing at push
time, so if anything, this will reduce the latency of the continuous
package build and deploy.
The push-to-master flow will now skip builds if it changes only the
docs.
This persuades the CI to install both the arm and intel flavors
of the rust toolchain on macOS, and the deploy script to generate
a universal binary.
* need big sur to build for M1
* Use cross-compilation compatible mlua from my fork for now
The mac builds started to fail with a crate resolution issue that I
can't reproduce locally shortly after I updated the cache action. Let's
tweak the cache key to see if that clears things up.
tweak some container names
fixup container names and regenerate the config
Ensure that curl is installed
the rust toolchain stuff wants curl
run apt update before apt install
centralize updating apt, and install sudo
revise get-deps script for slimmer debian images
more container related tweaks
get-deps: Don't require lsb-release on debianish systems
more get-deps improvements
Explicitly ask GH actions to recursively checkout the repo
Explicitly install git
fetch tags and tweak git build for debian systems
moar adjustments
remove deb8 (its wayland is too old), fixup debian publish
Ensure git build deps are installed always, tidy up sudo usage
