Bumps
[actions-rust-lang/setup-rust-toolchain](https://github.com/actions-rust-lang/setup-rust-toolchain)
from 1.5.0 to 1.6.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/actions-rust-lang/setup-rust-toolchain/blob/main/CHANGELOG.md">actions-rust-lang/setup-rust-toolchain's
changelog</a>.</em></p>
<blockquote>
<h2>[1.6.0] - 2023-12-04</h2>
<h3>Added</h3>
<ul>
<li>Allow disabling problem matchers (<a
href="https://redirect.github.com/actions-rust-lang/setup-rust-toolchain/issues/27">#27</a>)
This can be useful when having a matrix of jobs, that produce the same
errors.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="c7e1de2846"><code>c7e1de2</code></a>
Update CHANGELOG.md</li>
<li><a
href="24c9dd087b"><code>24c9dd0</code></a>
Merge pull request <a
href="https://redirect.github.com/actions-rust-lang/setup-rust-toolchain/issues/24">#24</a>
from obi1kenobi/patch-1</li>
<li><a
href="74a4154991"><code>74a4154</code></a>
Merge pull request <a
href="https://redirect.github.com/actions-rust-lang/setup-rust-toolchain/issues/27">#27</a>
from oxideai/feature/config-matcher</li>
<li><a
href="84ba0c9d1b"><code>84ba0c9</code></a>
Update README</li>
<li><a
href="51173b3da4"><code>51173b3</code></a>
feature(matcher): allow disabling problem matcher</li>
<li><a
href="33678a48c0"><code>33678a4</code></a>
Add docs for the <code>cachekey</code> output to the README</li>
<li><a
href="317ed62323"><code>317ed62</code></a>
Update example workflow in readme</li>
<li><a
href="8cb8f77172"><code>8cb8f77</code></a>
Merge pull request <a
href="https://redirect.github.com/actions-rust-lang/setup-rust-toolchain/issues/23">#23</a>
from actions-rust-lang/dependabot/github_actions/actio...</li>
<li><a
href="1f541c5b05"><code>1f541c5</code></a>
Bump actions/checkout from 3 to 4</li>
<li>See full diff in <a
href="https://github.com/actions-rust-lang/setup-rust-toolchain/compare/v1.5.0...v1.6.0">compare
view</a></li>
</ul>
</details>
<br />
[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=actions-rust-lang/setup-rust-toolchain&package-manager=github_actions&previous-version=1.5.0&new-version=1.6.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Fix release and nightly build workflow:
https://github.com/nushell/nightly/issues/15
I think the `mv` command in v0.87.1 still has some bugs, when downgrade
to v0.86 everything works as expected
# Description
I've had a few PRs fail clippy in CI after they pass `toolkit check pr`
because the clippy settings are different. This brings `toolkit.nu` into
alignment with CI and leaves notes to prompt future synchronization.
# User-Facing Changes
N/A
# Tests + Formatting
`cargo` output elided:
```
❯ toolkit check pr
running `toolkit fmt`
running `toolkit clippy`
running `toolkit clippy` on tests
running `toolkit clippy` on plugins
running `toolkit test`
running `toolkit test stdlib`
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
```
# After Submitting
N/A
# Description
This PR updates the release-pkg.nu script with updated instructions for
performing the release manually. These are there specifically because
winget fails so often and creating a x86_64 windows msi is not trivial.
There are also a couple minor changes to the script's syntax.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use std testing; testing run-tests --path
crates/nu-std"` to run the tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
Fix winget release submission error, more details could be found here:
https://github.com/nushell/nushell/pull/5812#issuecomment-1768294811
@fdncred @wolimst
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use std testing; testing run-tests --path
crates/nu-std"` to run the tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
### Update winget submission workflow include only default msi files:
---
The new release workflow after
https://github.com/nushell/nushell/pull/10457 will add full featured
packages like: `nu-*-x86_64-windows-msvc-full.msi` and
`nu-*-aarch64-windows-msvc-full.msi` (A release preview could be found
here: https://github.com/nushell/nightly/releases/tag/nightly-6a2fd91 )
and this change will make sure only the default packages will be
included just the same as before to make sure that nothing will be
broken.
BTW: Due to lots of changes made recently about the release workflow, I
will stand-by for the next release.
# Description
Add full releases of Nu binaries along with the standard releases,
close: https://github.com/nushell/nushell/issues/10322
A full release means:
1. Build with `--features=dataframe,extra` flag
2. Contains `-full` in the package name
### **A test release could be found in the nushell/nightly Repo:
https://github.com/nushell/nightly/releases/tag/v0.85.1**
The action running log:
https://github.com/nushell/nightly/actions/runs/6260611553
# User-Facing Changes
Will attach the following release packages along with the official ones
as before:
1. nu-*-aarch64-darwin-full.tar.gz
2. nu-*-aarch64-linux-gnu-full.tar.gz
3. nu-*-aarch64-windows-msvc-full.msi
4. nu-*-aarch64-windows-msvc-full.zip
5. nu-*-x86_64-darwin-full.tar.gz
6. nu-*-x86_64-linux-gnu-full.tar.gz
7. nu-*-x86_64-linux-musl-full.tar.gz
8. nu-*-x86_64-windows-msvc-full.msi
9. nu-*-x86_64-windows-msvc-full.zip
# Description
* The path to the binaries for tests is slightly incorrect. It is
missing the build target when it is set with the `CARGO_BUILD_TARGET`
environment variable. For example, when `CARGO_BUILD_TARGET` is set to
`aarch64-linux-android`, the path to the `nu` binary is:
`./target/aarch64-linux-android/debug/nu`
rather than
`./target/debug/nu`
This is common on Termux since the default target that rustc detects can
cause problems on some projects, such as [python's `cryptography`
package](https://github.com/pyca/cryptography/issues/7248).
This technically isn't a problem specific to Android, but is more likely
to happen on Android due to the latter.
* Additionally, the existing variable named `NUSHELL_CARGO_TARGET` is in
fact the profile, not the build target, so this was renamed to
`NUSHELL_CARGO_PROFILE`. This change is included because without the
rename, the build system would be using `CARGO_BUILD_TARGET` for the
build target and `NUSHELL_CARGO_TARGET` for the build profile, which is
confusing.
* `std path add` tests were missing `android` test
# User-Facing Changes
For those who would like to build nushell on Termux, the unit tests will
pass now.
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
`chrono` crate enables `oldtime` feature by default, which has a
vulnerability (https://rustsec.org/advisories/RUSTSEC-2020-0071). This
PR tries to remove `time` v0.1.45 completely from nu and add an audit CI
to check for security vulnerabilities.
✋ Wait for the following PRs:
- [x] https://github.com/nushell/reedline/pull/599
- [x] https://github.com/bspeice/dtparse/pull/44
- [x] https://github.com/Byron/trash-rs/pull/75
- [x] https://gitlab.com/imp/chrono-humanize-rs/-/merge_requests/15
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the
standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
---------
Co-authored-by: sholderbach <sholderbach@users.noreply.github.com>
# Description
We allowed two default lints due to false positives. This should be
locally addressed with explicit information what causes either a false
positive or why a particular design choice in the code is made.
# User-Facing Changes
None
# Tests + Formatting
We should detect a few more things with clippy out of the box. If you
encounter a false positive you will need to address it on a case by case
basis.
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
Winget Releaser now supports non-Windows runners, and `ubuntu-latest` is
generally faster.
# Description
this PR is an attempt at making the main CI workflow a bit easier to
read, understand and work with 🤞
## changelog
- remove the deprecated `nu-coverage` job which was taking place for
nothing
- remove useless comments, i.e. comments that just say the same thing as
the line they comment, e.g. the previous `on.push` comment, and comments
that can be explained with a `git blame` inside an IDE, e.g. the comment
about removing `--profile ci` on the `cargo install` in the std job
- rename `nu-fmt-clippy` and `nu-tests` to `fmt-clippy` and `tests` as
we already know we are working with Nushell
- rename the "*style*" to "*feature*" which is exactly what `default`,
`dataframe` and `extra` are
- remove the `strategy.matrix.rust: stable` key: i couldn't find any
documentation for this and it's not used in the jobs => by default, the
toolchain of `actions-rust-lang/setup-rust-toolchain@v1.5.0` is the
stable one (see the
[documentation](https://github.com/actions-rust-lang/setup-rust-toolchain#inputs))
- add a top-level `env` block with all the environment variables, e.g.
`CLIPPY_OPTIONS`, to have them all in one place
hope you'll like that 😇🙏
# User-Facing Changes
# Tests + Formatting
this PR should not change the different jobs being run in PRs and on the
`main` branch.
# After Submitting
# Description
For years, Nushell has used `let-env` to set a single environment
variable. As our work on scoping continued, we refined what it meant for
a variable to be in scope using `let` but never updated how `let-env`
would work. Instead, `let-env` confusingly created mutations to the
command's copy of `$env`.
So, to help fix the mental model and point people to the right way of
thinking about what changing the environment means, this PR removes
`let-env` to encourage people to think of it as updating the command's
environment variable via mutation.
Before:
```
let-env FOO = "BAR"
```
Now:
```
$env.FOO = "BAR"
```
It's also a good reminder that the environment owned by the command is
in the `$env` variable rather than global like it is in other shells.
# User-Facing Changes
BREAKING CHANGE BREAKING CHANGE
This completely removes `let-env FOO = "BAR"` so that we can focus on
`$env.FOO = "BAR"`.
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the
standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After / Before Submitting
integration scripts to update:
- ✔️
[starship](https://github.com/starship/starship/blob/master/src/init/starship.nu)
- ✔️
[virtualenv](https://github.com/pypa/virtualenv/blob/main/src/virtualenv/activation/nushell/activate.nu)
- ✔️
[atuin](https://github.com/ellie/atuin/blob/main/atuin/src/shell/atuin.nu)
(PR: https://github.com/ellie/atuin/pull/1080)
- ❌
[zoxide](https://github.com/ajeetdsouza/zoxide/blob/main/templates/nushell.txt)
(PR: https://github.com/ajeetdsouza/zoxide/pull/587)
- ✔️
[oh-my-posh](https://github.com/JanDeDobbeleer/oh-my-posh/blob/main/src/shell/scripts/omp.nu)
(pr: https://github.com/JanDeDobbeleer/oh-my-posh/pull/4011)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
This PR should fix#9565Close#9565
cc @hustcer
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the
standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
This PR refactors `cargo-build-nu`
cc @hustcer
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the
standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
Prevent `rustflags` build configuration from being ignored in github
actions ci workflows.
[actions-rust-lang/setup-rust-toolchain](https://github.com/actions-rust-lang/setup-rust-toolchain/)
used in ci workflows sets `RUSTFLAGS="-D warnings"` env variable by
default. It has priority over some other sources of `rustflags` as
described in [the cargo
reference](https://doc.rust-lang.org/cargo/reference/config.html#buildrustflags).
Nushell is using `target.x86_64-pc-windows-msvc.rustflags` to statically
link MSVC runtime in windows platform, but this config is being ignored
in ci workflows.
By unsetting `RUSTFLAGS` env variable, `rustflags` build configurations
will be properly used in ci workflows.
I assume that this was the cause of the installer verification failures
on the recent winget submission PRs. For more details, refer discussions
in https://github.com/microsoft/winget-pkgs/pull/106977 and
https://github.com/nushell/nushell/pull/9322#issuecomment-1602932971.
# User-Facing Changes
Pre-built releases for windows that are created by the release ci
workflow will now contain statically linked MSVC runtime.
# Tests + Formatting
Confirmed successful installation in a windows sandbox instance, which
was failing before. It also contains changes made in #9514.
Release ci workflow:
https://github.com/wolimst/nushell/actions/runs/5357440849
Installer: https://github.com/wolimst/nushell/releases/tag/0.81.0-test
# After Submitting
Need to check the installer verification result in a winget submission
PR for the next release, if this PR gets merged.
# Description
The issue template to report a build failure in our nightly-build CI was
also appearing among the options for a user to pick from.
Moved over to a separate folder `.github/AUTO_ISSUE_TEMPLATE`