mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
bf3030404e
rust/.travis.yml

70 lines
1.9 KiB
YAML
Raw Normal View History

Cache caro on Travis
2018-10-15 13:01:33 -05:00
cache: cargo
Don't cache ever changing stuff
2018-10-20 15:33:45 -05:00
before_cache:
speedup CI
2019-07-20 09:08:47 -05:00
# ask Cargo to clean up artifacts for workspace crates
- cargo clean $(printf -- '--package %s ' $(cd crates; ls))
# Cargo doesn't clean up depinfo itself, do it manually
- find ./target/debug -maxdepth 2 -iname '*.d' -delete
Reformat .travis.yml (using the vscode prettier extension) TODO: Check this on CI. Maybe we should change the prettier script in `editors/code`, or move it to somewhere else (`tests/format` maybe) Editing the script in editors/code would be easiest as that means we don't have to double install some shared `node_modules`
2018-12-29 04:31:20 -06:00
- rm -f ./target/.rustc_info.json
Don't cache ever changing stuff
2018-10-20 15:33:45 -05:00
Enforce rustfmt format
2018-01-27 17:31:23 -06:00
matrix:
Reformat .travis.yml (using the vscode prettier extension) TODO: Check this on CI. Maybe we should change the prettier script in `editors/code`, or move it to somewhere else (`tests/format` maybe) Editing the script in editors/code would be easiest as that means we don't have to double install some shared `node_modules`
2018-12-29 04:31:20 -06:00
include:
Run VS Code tests on CI This is actually much faster than I expected; it takes about 13 seconds to download VS Code and run the unit tests. This means the VS Code tests are still significantly faster than the Rust ones. If this ends up being unreliable we can always remove it later or move it to a separate optional job. We also need to ignore the `.vscode-test` directory when running `prettier` or it will get upset about some temporary JSON files VS Code creates.
2019-06-29 15:56:46 -05:00
- name: "Rust Tests"
os: linux
Use Xenial image and fix find call
2019-05-23 08:05:01 -05:00
dist: xenial
Remove windows from CI We don't actually look at the CI results for windows anyway! In general, rust-analyzer should be written in a completely OS-independent way. That is, testing on one OS should be enough. If this is not the case, that means something is seriously broken. No doubt there are components which actually talk to the outside world, and they may be platform dependent. We should extract such components to a separate repo with an extensive multi platform CI, like we did for VFS
2019-03-25 02:13:44 -05:00
language: rust
rust: stable
script:
- rustup component add rustfmt
- rustup component add rust-src
don't optimize on CI, it isn't faster
2019-07-22 10:19:57 -05:00
- printf "\n\n[profile.dev]\ndebug = false\n" >> Cargo.toml
Remove windows from CI We don't actually look at the CI results for windows anyway! In general, rust-analyzer should be written in a completely OS-independent way. That is, testing on one OS should be enough. If this is not the case, that means something is seriously broken. No doubt there are components which actually talk to the outside world, and they may be platform dependent. We should extract such components to a separate repo with an extensive multi platform CI, like we did for VFS
2019-03-25 02:13:44 -05:00
- cargo test --no-run # let's measure compile time separately
- cargo test
env:
- RUSTFLAGS="-D warnings", CARGO_INCREMENTAL=0
Run VS Code tests on CI This is actually much faster than I expected; it takes about 13 seconds to download VS Code and run the unit tests. This means the VS Code tests are still significantly faster than the Rust ones. If this ends up being unreliable we can always remove it later or move it to a separate optional job. We also need to ignore the `.vscode-test` directory when running `prettier` or it will get upset about some temporary JSON files VS Code creates.
2019-06-29 15:56:46 -05:00
- name: "Rust Docs"
os: linux
Remove windows from CI We don't actually look at the CI results for windows anyway! In general, rust-analyzer should be written in a completely OS-independent way. That is, testing on one OS should be enough. If this is not the case, that means something is seriously broken. No doubt there are components which actually talk to the outside world, and they may be platform dependent. We should extract such components to a separate repo with an extensive multi platform CI, like we did for VFS
2019-03-25 02:13:44 -05:00
if: branch = master AND type = push
fix build
2019-03-25 02:48:24 -05:00
before_script:
Add docs build
2019-03-23 14:43:38 -05:00
- DEPLOY_DOCS=1
Remove windows from CI We don't actually look at the CI results for windows anyway! In general, rust-analyzer should be written in a completely OS-independent way. That is, testing on one OS should be enough. If this is not the case, that means something is seriously broken. No doubt there are components which actually talk to the outside world, and they may be platform dependent. We should extract such components to a separate repo with an extensive multi platform CI, like we did for VFS
2019-03-25 02:13:44 -05:00
language: rust
rust: stable
script:
- cargo doc --all --no-deps
env:
- RUSTFLAGS="-D warnings", CARGO_INCREMENTAL=0
Run VS Code tests on CI This is actually much faster than I expected; it takes about 13 seconds to download VS Code and run the unit tests. This means the VS Code tests are still significantly faster than the Rust ones. If this ends up being unreliable we can always remove it later or move it to a separate optional job. We also need to ignore the `.vscode-test` directory when running `prettier` or it will get upset about some temporary JSON files VS Code creates.
2019-06-29 15:56:46 -05:00
- name: "VS Code Tests"
os: linux
language: node_js
dist: xenial
Reformat .travis.yml (using the vscode prettier extension) TODO: Check this on CI. Maybe we should change the prettier script in `editors/code`, or move it to somewhere else (`tests/format` maybe) Editing the script in editors/code would be easiest as that means we don't have to double install some shared `node_modules`
2018-12-29 04:31:20 -06:00
node_js: node
Run VS Code tests on CI This is actually much faster than I expected; it takes about 13 seconds to download VS Code and run the unit tests. This means the VS Code tests are still significantly faster than the Rust ones. If this ends up being unreliable we can always remove it later or move it to a separate optional job. We also need to ignore the `.vscode-test` directory when running `prettier` or it will get upset about some temporary JSON files VS Code creates.
2019-06-29 15:56:46 -05:00
services:
- xvfb
before_install: cd editors/code
install:
- npm install
- npm run vscode:prepublish
Reformat .travis.yml (using the vscode prettier extension) TODO: Check this on CI. Maybe we should change the prettier script in `editors/code`, or move it to somewhere else (`tests/format` maybe) Editing the script in editors/code would be easiest as that means we don't have to double install some shared `node_modules`
2018-12-29 04:31:20 -06:00
script:
Run VS Code tests on CI This is actually much faster than I expected; it takes about 13 seconds to download VS Code and run the unit tests. This means the VS Code tests are still significantly faster than the Rust ones. If this ends up being unreliable we can always remove it later or move it to a separate optional job. We also need to ignore the `.vscode-test` directory when running `prettier` or it will get upset about some temporary JSON files VS Code creates.
2019-06-29 15:56:46 -05:00
- npm ci
- npm run travis
env:
- CXX="g++-4.9", CC="gcc-4.9"
The last of the Masters
2018-01-27 18:23:05 -06:00
branches:
Reformat .travis.yml (using the vscode prettier extension) TODO: Check this on CI. Maybe we should change the prettier script in `editors/code`, or move it to somewhere else (`tests/format` maybe) Editing the script in editors/code would be easiest as that means we don't have to double install some shared `node_modules`
2018-12-29 04:31:20 -06:00
only:
- staging
- master
- trying
Add docs build
2019-03-23 14:43:38 -05:00
deploy:
provider: pages
skip-cleanup: true
github-token: $DOCS_TOKEN # Set in the settings page of your repository, as a secure variable
keep-history: true
local-dir: target/doc
branch: gh-pages
on:
branch: master
condition: $DEPLOY_DOCS = 1
Reference in New Issue Copy Permalink