Mirrors/nushell
2
0
Fork 0
mirror of https://github.com/nushell/nushell synced 2024-12-26 13:03:07 +00:00
Code Issues Projects Releases Packages Wiki Activity
nushell/.azure/azure-pipelines.yml

62 lines
1.9 KiB
YAML
Raw Normal View History

Try to add azure pipelines
2019-06-18 04:37:47 +00:00
trigger:
- master
strategy:
matrix:
Move azure pipeline to stable
2019-11-07 17:13:39 +00:00
linux-stable:
Bump Pipeline images (#1255) * Bump Pipeline images * Update azure-pipelines.yml * Update azure-pipelines.yml
2020-01-21 21:39:31 +00:00
image: ubuntu-18.04
Feature flagging infrastructure This commit adds the ability to work on features behind a feature flag that won't be included in normal builds of nu. These features are not exposed as Cargo features, as they reflect incomplete features that are not yet stable. To create a feature, add it to `features.toml`: ```toml [hintsv1] description = "Adding hints based on error states in the highlighter" enabled = false ``` Each feature in `features.toml` becomes a feature flag accessible to `cfg`: ```rs println!("hintsv1 is enabled"); ``` By default, features are enabled based on the value of the `enabled` field. You can also enable a feature from the command line via the `NUSHELL_ENABLE_FLAGS` environment variable: ```sh $ NUSHELL_ENABLE_FLAGS=hintsv1 cargo run ``` You can enable all flags via `NUSHELL_ENABLE_ALL_FLAGS`. This commit also updates the CI setup to run the build with all flags off and with all flags on. It also extracts the linting test into its own parallelizable test, which means it doesn't need to run together with every other test anymore. When working on a feature, you should also add tests behind the same flag. A commit is mergable if all tests pass with and without the flag, allowing incomplete commits to land on master as long as the incomplete code builds and passes tests.
2019-10-11 18:39:05 +00:00
style: 'unflagged'
Move azure pipeline to stable
2019-11-07 17:13:39 +00:00
macos-stable:
Bump the mac image version
2019-08-25 05:39:37 +00:00
image: macos-10.14
Feature flagging infrastructure This commit adds the ability to work on features behind a feature flag that won't be included in normal builds of nu. These features are not exposed as Cargo features, as they reflect incomplete features that are not yet stable. To create a feature, add it to `features.toml`: ```toml [hintsv1] description = "Adding hints based on error states in the highlighter" enabled = false ``` Each feature in `features.toml` becomes a feature flag accessible to `cfg`: ```rs println!("hintsv1 is enabled"); ``` By default, features are enabled based on the value of the `enabled` field. You can also enable a feature from the command line via the `NUSHELL_ENABLE_FLAGS` environment variable: ```sh $ NUSHELL_ENABLE_FLAGS=hintsv1 cargo run ``` You can enable all flags via `NUSHELL_ENABLE_ALL_FLAGS`. This commit also updates the CI setup to run the build with all flags off and with all flags on. It also extracts the linting test into its own parallelizable test, which means it doesn't need to run together with every other test anymore. When working on a feature, you should also add tests behind the same flag. A commit is mergable if all tests pass with and without the flag, allowing incomplete commits to land on master as long as the incomplete code builds and passes tests.
2019-10-11 18:39:05 +00:00
style: 'unflagged'
Move azure pipeline to stable
2019-11-07 17:13:39 +00:00
windows-stable:
Bump Pipeline images (#1255) * Bump Pipeline images * Update azure-pipelines.yml * Update azure-pipelines.yml
2020-01-21 21:39:31 +00:00
image: windows-2019
Feature flagging infrastructure This commit adds the ability to work on features behind a feature flag that won't be included in normal builds of nu. These features are not exposed as Cargo features, as they reflect incomplete features that are not yet stable. To create a feature, add it to `features.toml`: ```toml [hintsv1] description = "Adding hints based on error states in the highlighter" enabled = false ``` Each feature in `features.toml` becomes a feature flag accessible to `cfg`: ```rs println!("hintsv1 is enabled"); ``` By default, features are enabled based on the value of the `enabled` field. You can also enable a feature from the command line via the `NUSHELL_ENABLE_FLAGS` environment variable: ```sh $ NUSHELL_ENABLE_FLAGS=hintsv1 cargo run ``` You can enable all flags via `NUSHELL_ENABLE_ALL_FLAGS`. This commit also updates the CI setup to run the build with all flags off and with all flags on. It also extracts the linting test into its own parallelizable test, which means it doesn't need to run together with every other test anymore. When working on a feature, you should also add tests behind the same flag. A commit is mergable if all tests pass with and without the flag, allowing incomplete commits to land on master as long as the incomplete code builds and passes tests.
2019-10-11 18:39:05 +00:00
style: 'unflagged'
linux-nightly-canary:
Bump Pipeline images (#1255) * Bump Pipeline images * Update azure-pipelines.yml * Update azure-pipelines.yml
2020-01-21 21:39:31 +00:00
image: ubuntu-18.04
Feature flagging infrastructure This commit adds the ability to work on features behind a feature flag that won't be included in normal builds of nu. These features are not exposed as Cargo features, as they reflect incomplete features that are not yet stable. To create a feature, add it to `features.toml`: ```toml [hintsv1] description = "Adding hints based on error states in the highlighter" enabled = false ``` Each feature in `features.toml` becomes a feature flag accessible to `cfg`: ```rs println!("hintsv1 is enabled"); ``` By default, features are enabled based on the value of the `enabled` field. You can also enable a feature from the command line via the `NUSHELL_ENABLE_FLAGS` environment variable: ```sh $ NUSHELL_ENABLE_FLAGS=hintsv1 cargo run ``` You can enable all flags via `NUSHELL_ENABLE_ALL_FLAGS`. This commit also updates the CI setup to run the build with all flags off and with all flags on. It also extracts the linting test into its own parallelizable test, which means it doesn't need to run together with every other test anymore. When working on a feature, you should also add tests behind the same flag. A commit is mergable if all tests pass with and without the flag, allowing incomplete commits to land on master as long as the incomplete code builds and passes tests.
2019-10-11 18:39:05 +00:00
style: 'canary'
macos-nightly-canary:
image: macos-10.14
style: 'canary'
windows-nightly-canary:
Bump Pipeline images (#1255) * Bump Pipeline images * Update azure-pipelines.yml * Update azure-pipelines.yml
2020-01-21 21:39:31 +00:00
image: windows-2019
Feature flagging infrastructure This commit adds the ability to work on features behind a feature flag that won't be included in normal builds of nu. These features are not exposed as Cargo features, as they reflect incomplete features that are not yet stable. To create a feature, add it to `features.toml`: ```toml [hintsv1] description = "Adding hints based on error states in the highlighter" enabled = false ``` Each feature in `features.toml` becomes a feature flag accessible to `cfg`: ```rs println!("hintsv1 is enabled"); ``` By default, features are enabled based on the value of the `enabled` field. You can also enable a feature from the command line via the `NUSHELL_ENABLE_FLAGS` environment variable: ```sh $ NUSHELL_ENABLE_FLAGS=hintsv1 cargo run ``` You can enable all flags via `NUSHELL_ENABLE_ALL_FLAGS`. This commit also updates the CI setup to run the build with all flags off and with all flags on. It also extracts the linting test into its own parallelizable test, which means it doesn't need to run together with every other test anymore. When working on a feature, you should also add tests behind the same flag. A commit is mergable if all tests pass with and without the flag, allowing incomplete commits to land on master as long as the incomplete code builds and passes tests.
2019-10-11 18:39:05 +00:00
style: 'canary'
fmt:
Bump Pipeline images (#1255) * Bump Pipeline images * Update azure-pipelines.yml * Update azure-pipelines.yml
2020-01-21 21:39:31 +00:00
image: ubuntu-18.04
Feature flagging infrastructure This commit adds the ability to work on features behind a feature flag that won't be included in normal builds of nu. These features are not exposed as Cargo features, as they reflect incomplete features that are not yet stable. To create a feature, add it to `features.toml`: ```toml [hintsv1] description = "Adding hints based on error states in the highlighter" enabled = false ``` Each feature in `features.toml` becomes a feature flag accessible to `cfg`: ```rs println!("hintsv1 is enabled"); ``` By default, features are enabled based on the value of the `enabled` field. You can also enable a feature from the command line via the `NUSHELL_ENABLE_FLAGS` environment variable: ```sh $ NUSHELL_ENABLE_FLAGS=hintsv1 cargo run ``` You can enable all flags via `NUSHELL_ENABLE_ALL_FLAGS`. This commit also updates the CI setup to run the build with all flags off and with all flags on. It also extracts the linting test into its own parallelizable test, which means it doesn't need to run together with every other test anymore. When working on a feature, you should also add tests behind the same flag. A commit is mergable if all tests pass with and without the flag, allowing incomplete commits to land on master as long as the incomplete code builds and passes tests.
2019-10-11 18:39:05 +00:00
style: 'fmt'
Try to add azure pipelines
2019-06-18 04:37:47 +00:00
pool:
vmImage: $(image)
steps:
- bash: |
set -e
Update azure-pipelines.yml
2019-10-02 16:27:03 +00:00
if [ -e /etc/debian_version ]
then
sudo apt-get -y install libxcb-composite0-dev libx11-dev
fi
Bump Pipeline images (#1255) * Bump Pipeline images * Update azure-pipelines.yml * Update azure-pipelines.yml
2020-01-21 21:39:31 +00:00
if [ "$(uname)" == "Darwin" ]; then
curl https://sh.rustup.rs -sSf | sh -s -- -y --no-modify-path --default-toolchain "stable"
export PATH=$HOME/.cargo/bin:$PATH
rustup update
fi
Try to add azure pipelines
2019-06-18 04:37:47 +00:00
rustc -Vv
echo "##vso[task.prependpath]$HOME/.cargo/bin"
Bump Pipeline images (#1255) * Bump Pipeline images * Update azure-pipelines.yml * Update azure-pipelines.yml
2020-01-21 21:39:31 +00:00
rustup component add rustfmt
Try to add azure pipelines
2019-06-18 04:37:47 +00:00
displayName: Install Rust
Keep dummies in default features for convenience. (#1212)
2020-01-13 06:17:56 +00:00
- bash: RUSTFLAGS="-D warnings" cargo test --all --features=stable
Feature flagging infrastructure This commit adds the ability to work on features behind a feature flag that won't be included in normal builds of nu. These features are not exposed as Cargo features, as they reflect incomplete features that are not yet stable. To create a feature, add it to `features.toml`: ```toml [hintsv1] description = "Adding hints based on error states in the highlighter" enabled = false ``` Each feature in `features.toml` becomes a feature flag accessible to `cfg`: ```rs println!("hintsv1 is enabled"); ``` By default, features are enabled based on the value of the `enabled` field. You can also enable a feature from the command line via the `NUSHELL_ENABLE_FLAGS` environment variable: ```sh $ NUSHELL_ENABLE_FLAGS=hintsv1 cargo run ``` You can enable all flags via `NUSHELL_ENABLE_ALL_FLAGS`. This commit also updates the CI setup to run the build with all flags off and with all flags on. It also extracts the linting test into its own parallelizable test, which means it doesn't need to run together with every other test anymore. When working on a feature, you should also add tests behind the same flag. A commit is mergable if all tests pass with and without the flag, allowing incomplete commits to land on master as long as the incomplete code builds and passes tests.
2019-10-11 18:39:05 +00:00
condition: eq(variables['style'], 'unflagged')
displayName: Run tests
Keep dummies in default features for convenience. (#1212)
2020-01-13 06:17:56 +00:00
- bash: RUSTFLAGS="-D warnings" cargo clippy --all --features=stable -- -D clippy::result_unwrap_used -D clippy::option_unwrap_used
Move to using clippy (#1142) * Clippy fixes * Finish converting to use clippy * fix warnings in new master * fix windows * fix windows Co-authored-by: Artem Vorotnikov <artem@vorotnikov.me>
2019-12-31 07:36:08 +00:00
condition: eq(variables['style'], 'unflagged')
displayName: Check clippy lints
Keep dummies in default features for convenience. (#1212)
2020-01-13 06:17:56 +00:00
- bash: NUSHELL_ENABLE_ALL_FLAGS=1 RUSTFLAGS="-D warnings" cargo test --all --features=stable
Feature flagging infrastructure This commit adds the ability to work on features behind a feature flag that won't be included in normal builds of nu. These features are not exposed as Cargo features, as they reflect incomplete features that are not yet stable. To create a feature, add it to `features.toml`: ```toml [hintsv1] description = "Adding hints based on error states in the highlighter" enabled = false ``` Each feature in `features.toml` becomes a feature flag accessible to `cfg`: ```rs println!("hintsv1 is enabled"); ``` By default, features are enabled based on the value of the `enabled` field. You can also enable a feature from the command line via the `NUSHELL_ENABLE_FLAGS` environment variable: ```sh $ NUSHELL_ENABLE_FLAGS=hintsv1 cargo run ``` You can enable all flags via `NUSHELL_ENABLE_ALL_FLAGS`. This commit also updates the CI setup to run the build with all flags off and with all flags on. It also extracts the linting test into its own parallelizable test, which means it doesn't need to run together with every other test anymore. When working on a feature, you should also add tests behind the same flag. A commit is mergable if all tests pass with and without the flag, allowing incomplete commits to land on master as long as the incomplete code builds and passes tests.
2019-10-11 18:39:05 +00:00
condition: eq(variables['style'], 'canary')
Remove (unneeded?) parts of the pipeline
2019-06-18 18:59:34 +00:00
displayName: Run tests
Keep dummies in default features for convenience. (#1212)
2020-01-13 06:17:56 +00:00
- bash: NUSHELL_ENABLE_ALL_FLAGS=1 RUSTFLAGS="-D warnings" cargo clippy --all --features=stable -- -D clippy::result_unwrap_used -D clippy::option_unwrap_used
Move to using clippy (#1142) * Clippy fixes * Finish converting to use clippy * fix warnings in new master * fix windows * fix windows Co-authored-by: Artem Vorotnikov <artem@vorotnikov.me>
2019-12-31 07:36:08 +00:00
condition: eq(variables['style'], 'canary')
displayName: Check clippy lints
install correct version
2019-09-11 17:49:16 +00:00
- bash: cargo fmt --all -- --check
Feature flagging infrastructure This commit adds the ability to work on features behind a feature flag that won't be included in normal builds of nu. These features are not exposed as Cargo features, as they reflect incomplete features that are not yet stable. To create a feature, add it to `features.toml`: ```toml [hintsv1] description = "Adding hints based on error states in the highlighter" enabled = false ``` Each feature in `features.toml` becomes a feature flag accessible to `cfg`: ```rs println!("hintsv1 is enabled"); ``` By default, features are enabled based on the value of the `enabled` field. You can also enable a feature from the command line via the `NUSHELL_ENABLE_FLAGS` environment variable: ```sh $ NUSHELL_ENABLE_FLAGS=hintsv1 cargo run ``` You can enable all flags via `NUSHELL_ENABLE_ALL_FLAGS`. This commit also updates the CI setup to run the build with all flags off and with all flags on. It also extracts the linting test into its own parallelizable test, which means it doesn't need to run together with every other test anymore. When working on a feature, you should also add tests behind the same flag. A commit is mergable if all tests pass with and without the flag, allowing incomplete commits to land on master as long as the incomplete code builds and passes tests.
2019-10-11 18:39:05 +00:00
condition: eq(variables['style'], 'fmt')
CI
2019-09-11 17:06:59 +00:00
displayName: Lint
Restructure and streamline token expansion (#1123) Restructure and streamline token expansion The purpose of this commit is to streamline the token expansion code, by removing aspects of the code that are no longer relevant, removing pointless duplication, and eliminating the need to pass the same arguments to `expand_syntax`. The first big-picture change in this commit is that instead of a handful of `expand_` functions, which take a TokensIterator and ExpandContext, a smaller number of methods on the `TokensIterator` do the same job. The second big-picture change in this commit is fully eliminating the coloring traits, making coloring a responsibility of the base expansion implementations. This also means that the coloring tracer is merged into the expansion tracer, so you can follow a single expansion and see how the expansion process produced colored tokens. One side effect of this change is that the expander itself is marginally more error-correcting. The error correction works by switching from structured expansion to `BackoffColoringMode` when an unexpected token is found, which guarantees that all spans of the source are colored, but may not be the most optimal error recovery strategy. That said, because `BackoffColoringMode` only extends as far as a closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in fairly granular correction strategy. The current code still produces an `Err` (plus a complete list of colored shapes) from the parsing process if any errors are encountered, but this could easily be addressed now that the underlying expansion is error-correcting. This commit also colors any spans that are syntax errors in red, and causes the parser to include some additional information about what tokens were expected at any given point where an error was encountered, so that completions and hinting could be more robust in the future. Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com> Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 22:45:03 +00:00
Reference in a new issue Copy permalink