It's currently failing when running tests with errors of the form:
> error: creating test list failed
>
> Caused by:
> for `wezterm-config-derive`, command
> `'D:\a\wezterm\wezterm\target\debug\deps\wezterm_config_derive-f1c7f0f2de220b6e.exe'
> --list --format terse` exited with code 0xc0000135: The specified
> module could not be found. (os error 126)
This seems to have been caused by nextest-rs/nextest#1493, with this comment
as a fix: https://github.com/nextest-rs/nextest/issues/1493#issuecomment-2106331574
The original thinking was to build all in release mode so that
there was less overall redundancy between building out the released
binaries and what we need to build for test purposes. The goal was to
minimize compile time.
I don't believe that that holds up any more, especially with the
prior commit explicitly breaking out the separate binary builds
to manage dependency bloat.
In particular, strip-ansi-escapes' dep graph is expanded
by the overall set of enabled crate features when doing an
indiscriminate `cargo build` vs. `cargo build -p strip-ansi-escapes`.
This may help to avoid tripping over whatever is problematic
in https://github.com/wez/wezterm/issues/5074
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.
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.
