Currently we run 7 different jobs:
- tests linux
- tests macos
- tests windows
- rustfmt
- clippy
- examples
- documentation
With this change I reduced them to 4 and hopefully sped them up.
The total execution time is limited by the tests, especially linux that calculates coverage. Having separate jobs for clippy and rustfmt (which take a very small amount of time) is a waste of energy.
With this PR:
Introduced a new cargo profile, `ci`, that should create smaller sized binaries and reduce the our cache usage.
I changed the test runner for macos and windows to [nextest](https://nexte.st/), which should be faster and is specifically designed for CI.
I merged all smaller tasks in a single job, misc, the steps clearly identify what is being tested so it shouldn't affect clarity.
Switched to using the [rust-cache](https://github.com/Swatinem/rust-cache) GH action, this simplifies our work by no longer having to worry about which directories to cache, rust-cache handles all that for us.
~~The bors task should also be modified, I'll get to it as soon as I have time. I believe it should be possible for us to have a single workflow described and have it both be the normal CI and the bors test.~~
This Pull Request fixes the bors hanging we've had recently
The vm action had been removed but bors was still waiting for it
It changes the following:
- Remove 'Tests on Linux with vm enabled' from the actions to be waited for
This Pull Request updates some of our CI config and adds config for bors.
It changes the following:
- remove `cargo check` from CI (`cargo test` should be enough)
- change back to `cargo tarpaulin` on Linux to get coverage information
- simplify some of the CI steps' names
- add workflow for bors
##### Working with bors
It's setup so that we need 2 approvals before we can merge like we discussed in Discord.
After the second approval we can write a comment with `bors r+` so that the merge is tested.
bors will only run if `test`, `rustfmt`, `clippy`, `examples` and `doc` are all running error free in the PR's branch. It will then run them again in a `staging` branch that is the equivalent of merging the PR on `main`.
Another option we can consider is `up_to_date_approvals`, so that new commits make previous approvals not count.
The bors reference can be found here: https://bors.tech/documentation/
João Borges