<!--
Thanks for contributing to Nushell!
Before submitting, please read the contributing guide:
https://github.com/nushell/nushell/blob/main/CONTRIBUTING.md
This template helps reviewers understand your changes and allows us to
generate high-quality release notes.
-->
## Description
<!--
Explain what this PR does and why.
This section is intentionally flexible:
- Describe the problem
- Explain your approach
- Include technical details if relevant
Good examples:
- "In this PR, I fixed..."
- "In this PR, I added support for..."
- "This change improves X by..."
Write as much or as little as needed for reviewers to understand your
changes.
-->
This PR changes how the CI uploads its artifacts to further testing and
for download via the toolkit. In fact this PR is a complete rewrite of
our `ci.yml` to be hopefully more straightforward.
I also fixed the `toolkit run pr` command on windows. And the binaries
built by ci include in their `version` command a `build_pr` field that
references the pr that caused this binary to build.
## User-facing changes (Release notes)
<!--
This section is used (mostly as-is) for https://www.nushell.sh/blog/
Describe how Nushell behavior changes from a user's perspective.
Do NOT describe internal Rust changes here.
Write in a release note style, for example:
- "Added support for..."
- "Fixed an issue where..."
- "Nushell now supports..."
- "Improved performance of..."
If your changes do NOT affect users (internal refactors, cleanup, etc.),
just write:
- "n/a"
- "nan"
- or similar
This tells us the change should not appear in the changelog.
Tips:
- Focus on observable behavior
- Include examples if helpful
- Keep it concise
You can:
- Write a short paragraph (will appear as a bullet point), OR
- Use headings (###) if your change needs more structure
Avoid writing things like:
- "In this PR, I refactored..."
- "This updates internal code..."
You may leave this blank until the PR is ready.
-->
n/a
---------
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
<!--
Thanks for contributing to Nushell!
Before submitting, please read the contributing guide:
https://github.com/nushell/nushell/blob/main/CONTRIBUTING.md
This template helps reviewers understand your changes and allows us to
generate high-quality release notes.
-->
## Description
This PR disallows keywords from being shadowed such as `def def [] {}`.
I'm calling this a breaking change because we had to change `toolkit
run` to `toolkit dev` because `run` is now a keyword.
<!--
Explain what this PR does and why.
This section is intentionally flexible:
- Describe the problem
- Explain your approach
- Include technical details if relevant
Good examples:
- "In this PR, I fixed..."
- "In this PR, I added support for..."
- "This change improves X by..."
Write as much or as little as needed for reviewers to understand your
changes.
-->
## User-facing changes (Release notes)
Trying to shadow a keyword will produce an error now.
```nushell
❯ def def [] {}
Error: nu::parser::name_is_keyword
× Can't use parser keyword `def` as command name.
╭─[repl_entry #1:1:5]
1 │ def def [] {}
· ─┬─
· ╰── 'def' is a parser keyword
╰────
help: Parser keywords cannot be shadowed (including via module exports and `use *`). Choose a different command name so language
constructs keep working.
```
<!--
This section is used (mostly as-is) for https://www.nushell.sh/blog/
Describe how Nushell behavior changes from a user's perspective.
Do NOT describe internal Rust changes here.
Write in a release note style, for example:
- "Added support for..."
- "Fixed an issue where..."
- "Nushell now supports..."
- "Improved performance of..."
If your changes do NOT affect users (internal refactors, cleanup, etc.),
just write:
- "n/a"
- "nan"
- or similar
This tells us the change should not appear in the changelog.
Tips:
- Focus on observable behavior
- Include examples if helpful
- Keep it concise
You can:
- Write a short paragraph (will appear as a bullet point), OR
- Use headings (###) if your change needs more structure
Avoid writing things like:
- "In this PR, I refactored..."
- "This updates internal code..."
You may leave this blank until the PR is ready.
-->
## Additional notes
<!--
Optional.
Examples:
- fixes#123
- closes#456
- related #789
Anything else reviewers should know.
Remove this section if not needed.
-->
## Description
A command annotated to return `int` was returning `string`.
This wasn't caught until recently, as the return value wasn't used in an
operation that wouldn't also accept `string`.
Enabling `enforce-runtime-annotations` (which has been made opt-out
recently) caused type checking to occur on the call site (`return`
itself is not type checked yet):
```nushell
let workflow_id = get-workflow-run $commits $number.span
# $workflow_id is inferred to be `int` due to `get-workflow-run`'s signature,
# so it's equivalent to:
let workflow_id: int = get-workflow-run $commits $number.span
```
## User-facing changes (Release notes)
N/A
Based on a Discord discussion yesterday where it was pointed out that
`home-path` and `temp-path` are inconsistently named when compared to
the other *directories* in `$nu`.
## Release notes summary - What our users need to know
For consistency with other `$nu` fields:
* `$nu.temp-path` has been renamed to `$nu.temp-dir`
* `$nu.home-path` has been renamed to `$nu.home-dir`
## Tasks after submitting
- [ ] Update the
[documentation](https://github.com/nushell/nushell.github.io)
This PR adds the `toolkit run pr` and `toolkit download pr` commands to
`toolkit`. This is a more fleshed out version of the snippet shared in
#16633, with robust error handling and cross-platform unzip support.
When using `toolkit run pr`, the script will also check if the most
recent binary for that PR has already been downloaded, and if so it will
run that instead.
I tried to make the error reporting as good as a built-in command to see
how difficult that would be, and with use of the `--head: oneof<>`
trick, it turned out pretty good. With access to the call span, the
workflow is very similar to when writing a built-in command. I also used
a `Spanned`-like record, which helped as well.
```nushell
toolkit run pr 16740
# => Error: nu::shell::error
# =>
# => × Command not found
# => ╭─[entry #4:1:26]
# => 1 │ overlay use -pr toolkit; toolkit run pr 16740
# => · ───────┬──────
# => · ╰── requires `gh`
# => ╰────
# => help: Please install the `gh` commandline tool
```
<details>
<summary>More error reporting notes</summary>
In an earlier version of the script, `run pr` called `download pr`
directly. I ended up changing the way this worked so that `run pr` could
use the workflow_id. Here's a couple snippets I thought were neat from
this older version.
**Passing span via `--head`:**
```nushell
def download [--head: oneof<>] {
let span = $head | default (metadata $head).span
error make {msg: "a", label: {text: here, span: $span}}
}
def run [--head: oneof<>] {
let span = (metadata $head).span
download --head=$span
}
download
# => Error: nu::shell::error
# =>
# => × a
# => ╭─[entry #6:1:1]
# => 1 │ download
# => · ────┬───
# => · ╰── here
# => ╰────
run
# => Error: nu::shell::error
# =>
# => × a
# => ╭─[entry #7:1:1]
# => 1 │ run
# => · ─┬─
# => · ╰── here
# => ╰────
```
**Using "spanned" number as CLI parameter and as internal caller
parameter**
```nushell
def download [number: oneof<int, record<item: int, span: record>>] {
let number = match $number {
{item: $_, span: $_} => $number,
$val => {item: $number, span: (metadata $number).span}
}
error make {msg: "a", label: {text: here, span: $number.span}}
}
def run [number: int] {
let number = {item: $number, span: (metadata $number).span}
download $number
}
download 123
# => Error: nu::shell::error
# =>
# => × a
# => ╭─[entry #9:1:10]
# => 1 │ download 123
# => · ─┬─
# => · ╰── here
# => ╰────
run 123
# => Error: nu::shell::error
# =>
# => × a
# => ╭─[entry #10:1:5]
# => 1 │ run 123
# => · ─┬─
# => · ╰── here
# => ╰────
```
</details>
## Release notes summary - What our users need to know
The toolkit in the Nushell repository can now download and run PRs by
downloading artifacts from CI runs. It can be run like this:
```nushell
use toolkit
toolkit run pr <number>
```
Refactors the toolkit into a module. Was getting a bit large
This PR preserves the actual `toolkit.nu` file by making it `export use
toolkit *`. This way, anyone using `use toolkit.nu` can still expect it
to work the same way. This does have the unfortunate side effect that it
introduces a `toolkit toolkit` command, which does the same thing as
just `toolkit` (i.e., runs `help main`)
