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.
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.
On CI, we remove this project's artifacts from ./target before caching
it. This way, cache never changes, because it only caches deps.
We do this approximatelly, and, together with our own tools crate, we
also remove itertools, which are used by some other deps. Given that
tools change rarely, let's just cache them?
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
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`
215: Add Travis Windows build r=matklad a=phansch
This adds the Windows build to Travis.
I had to use the `dos2unix` utility on the parser directory to fix some incorrect
line endings. I'm not sure where they are coming from but I guess git is
converting them automatically when cloning on Windows.
Closes#139
Co-authored-by: Philipp Hansch <dev@phansch.net>
