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

66 lines
1.7 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:
switch back to old cleaning strategy Turns out, Cargo is pretty bad at cleaning after itself: I see .rmeta, .rlib and .d files after clean :(
2019-07-24 04:35:00 -05:00
- find ./target/debug -maxdepth 1 -type f -delete
move syntax tests to unit tests
2019-07-24 04:38:21 -05:00
- rm -fr ./target/debug/{deps,.fingerprint}/{*ra_*,*heavy_test*,*gen_lsp*,*thread_worker*}
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
save disk space
2019-10-11 03:06:28 -05:00
- sed -i "s/debug = 1/debug = false/g" 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:
start GitHub pages
2019-09-02 06:42:23 -05:00
- cargo build-website
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
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:
install npm deps once
2019-07-29 03:13:16 -05:00
- npm ci
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 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 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
don't keep history for gh-pages docs weigh a lot, and change a lot. Keeping their changes in history inflates repo size. By specifying `keep-history: false` we should be able to avoid that.
2019-10-04 16:40:35 -05:00
keep-history: false
start GitHub pages
2019-09-02 06:42:23 -05:00
local-dir: target/website/
Add docs build
2019-03-23 14:43:38 -05:00
on:
branch: master
condition: $DEPLOY_DOCS = 1
Reference in New Issue Copy Permalink