### Continuous integration
There are two "levels" of CI:
* Small subset run on pull request directly (most tests but only for linux x64)
* Full run of all tests for all platforms
Nothing can be merged if the CI doesn't pass!
### Build queue
[bors.rust-lang.org/queue/rust](https://bors.rust-lang.org/queue/rust)

### What is tested?
* Compiletest
* Unit tests
* Rustc and Rustdoc error output
* Documentation examples
* All tools tests (cargo, rustdoc, clippy, rustfmt, etc)
* Documentation dead links
* And quite a lot more!
### On which OS/architecture?
* Tier 1 platforms: Must build and pass test
* Tier 2 platforms: Must build
* Tier 3 plaftorms: Exists
Target tier policy:
[doc.rust-lang.org/nightly/rustc/target-tier-policy.html](https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html)
List of platforms for each tier:
[doc.rust-lang.org/rustc/platform-support.html](https://doc.rust-lang.org/rustc/platform-support.html)
### What about releases?
In (very) short:
1. bors build queue is frozen.
2. beta and stable branches are updated.
3. All relevant information is updated everywhere.
4. Binaries are generated for all plaftorms.
5. Blog post is released.
Performance
Pull request was merged, but now it's time to check for performance impact.
perf.rust-lang.org
### Other cases
Adding a new feature or introducing a breaking changes. Three possibilities:
* RFC (Request For Comments): for big changes
* MCP (Major Compiler Changes): for "not too big" changes in the compiler
* FCP (Final Comment Period): for "not too big" changes
Checking for potential regressions
In case a pull request changes things that could introduce a regression, we use crater.