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.
* add workflow for pushing nix flake artifacts to Cachix
* add docs on using the cachix cache from nix
* remove submodule clone from cachix workflow
* remove flake check
We ran the tests first, but did not cross compile them. This step would
also compile all the grammar libraries (but for the host machine). On
the actual release build, the editor would get built for the target, but
the grammar libraries would be detected as present and wouldn't
recompile.
Refs #577
Michael Davis
Blaž Hrastnik
Matthew Toohey
Benedikt Müller
dependabot[bot]
Ivan Tham
Gokul Soumya
Thanabodee Charoenpiriyakij
kabirz
wojciechkepka