Expands the trigger sources of the release CI workflow (`release.yml`),
allowing the developers to test changes to `.github/workflows/release.yml`
easily. The new trigger sources start the workflow in a "preview" mode, in
which it publishes build outputs as a CI artifact instead of creating a new
release so that they can be manually inspected.
The following events trigger the preview mode:
- Pushing to any branch matching the glob pattern `patch/ci-release-*`.
- Opening a pull request that modifies `.github/workflows/release.yml`.
- Pushing versioning tags to a forked repository.
The tests are conditionally disabled for this target because the x86_64 CI
host is unable to run AArch64 binaries. (There is no officially-supported
reverse Rosetta 2.)
This is an optimization for the release CI. The release CI can take
a while since it compiles release builds for all operating systems.
We cut down on duplicate work and overall time by fetching
tree-sitter grammar repositories and then using those repositories
in all later steps. Previously we built all of helix just to run
helix_loader::grammar::fetch_grammars()
which is wasteful on time. With this change we only build the
helix-loader crate.
This line uses the Display trait for io::ErrorKind which was
stabilized in Rust 1.60.0. We can set MSRV all the way back to
1.57.0 by replacing it with a pretty-print.
Closes#2460.
It's very easy to use new rust features without realizing it since
the CI and local development workflows may use the latest rust version.
We try to keep some backwards compatibility with rust versions to make
packaging easier for some OS-level package-managers like Void Linux's.
See #1881.
This change runs the "Check" step for the pinned version of rust in
the rust-toolchain.toml file as well as the MSRV version in a matrix.
In order to bump the MSRV, we need to edit
.github/workflows/msrv-rust-toolchain.toml
This commit sets the MSRV as 1.60.0 but a later child commit will
reduce the MSRV back to 1.57.0.
Closes#2482.
We've forked actions-rs/toolchain and merged
https://github.com/actions-rs/toolchain/pull/209
so we can take advantage of full support of `rust-toolchain.toml`.
Without that PR, the action fails because the `rustup` version
built into the runners by default is too old. #2528 covers switching
back to the upstream when it includes those changes.
* publish a source tarball with version and grammars
* include_str! the release version from a VERSION file
* remove setting of .version file from tag
don't need this anymore since the file is checked into source
`restore-keys` is a configuration option for the actions/cache action
which specifies fallback behavior. The [docs][docs] say it best:
> When a cache miss occurs, the action searches for alternate keys
> called `restore-keys`.
>
> If you provide `restore-keys`, the `cache` action sequentially
> searches for any caches that match the list of `restore-keys`.
> ... If there are no exact matches, the action searches for partial
> matches of the restore keys. When the action finds a partial match,
> the most recent cache is restored to the `path` directory.
So this improves caching when there's a miss. For example if I edit
`.github/workflows/languages.toml`, the current behavior is that the
cache for downloaded grammars will miss and all of them will need to
be fetched again. With `restore-keys`, we use the latest published
cache as 'good enough', we'll fetch whatever grammars changed, and
then at the end we publish a new cache under the new hash.
[docs]: https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#example-using-the-cache-action
79caa7b72b setup helix-term as the
default workspace member (which I believe is done to avoid building
xtask on every compile). This changes the behavior of 'cargo test'
though so that it only runs helix-term tests by default. To run all
tests, we switch to 'cargo test --workspace'.
This restores much of the behavior that existed before this PR:
helix will build the grammars when compiling. The difference is that
now fetching is also done during the build phase and is done much
more quickly - both shallow and in parallel.
