| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Initialize llvm submodule if not already the case to run citool
While working on https://github.com/rust-lang/rust/pull/146414, I ran the following command (to run CI docker locally):
```
cargo run --manifest-path src/ci/citool/Cargo.toml run-local --type pr x86_64-gnu-gcc
```
However, since I didn't have `src/llvm` submodule initialized, it failed. Apparently it's a common issue for people using this tool so this PR removes this small inconvenience.
r? ``@Kobzol``
|
|
|
|
|
|
|
|
|
|
To prevent possibility of a PR with red PR-only CI passing Auto CI, then
all subsequent PR CI runs will be red until that is fixed.
Note that this is **not** a "strict" subset relationship: some jobs
necessarily have to differ under PR CI and Auto CI environments. For
instance:
- `x86_64-gnu-tools` will have auto-only env vars like
`DEPLOY_TOOLSTATES_JSON: toolstates-linux.json`.
- `tidy` will want to `continue_on_error: true` in PR CI to allow for
more "useful" compilation errors to also be reported, whereas it needs
to `continue_on_error: false` in Auto CI to prevent wasting Auto CI
resources.
The carve-outs are:
1. `env` variables.
2. `continue_on_error`.
|
|
Rename `mingw-*` CI jobs to `pr-*`
The name `mingw` confuses people because these CI jobs now do much more than just cross-compile to mingw.
This is basically a find/replace. I chose the name `pr-` because it's job is to do general PR checks,
|
|
|
|
|
|
|
|
This allows us to reuse its cache on PR CI jobs.
|
|
So that we can make sure that they are reproducible locally.
|
|
They couldn't be executed locally before due to some additional environment reads.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
|
|
|
|
|
|
|
|
`assembly/asm` contained a test named `asm/aarch64-el2vmsa.rs`, while it should have been only `arch64-el2vmsa.rs`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
0.8.7 can trigger a panic when debug assertions are enabled when used via flate2 in some cases
|
|
Add job summary links to post-merge report
This should make it much easier to investigate the individual job test/duration changes.
The GitHub API handling is a bit crude, but I didn't want to include octocrab, because it more than doubles the current number of dependencies of `citool`...
Can be tested with:
```bash
$ cargo run --manifest-path src/ci/citool/Cargo.toml post-merge-report bad13a970a136389187dd1cf2f2fc737a8bea5fc 1e008dd5d83e782ad37fc9cf6824733f824cc8cd
```
r? ```@marcoieni```
|
|
This should make it much easier to investigate the individual job changes.
|
|
It was supposed to be like this from the start, but I forgot to apply the `abs` operation, as I got sidetracked with how to actually compare floats...
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
This will allow us to provide links to CI workflows, jobs and summaries in the post-merge analysis report.
|
|
|
|
|
|
|
|
Add bootstrap step diff to CI job analysis
This PR adds another analysis to the job analysis report in GitHub summary. It compares (diffs) bootstrap steps executed by the parent run and by the current commit. This will help us figure out if the bootstrap invocation did something different than before, and also how did the duration of individual steps and bootstrap invocations change.
Can be tested on the https://github.com/rust-lang/rust/pull/119899 PR like this:
```bash
$ curl https://ci-artifacts.rust-lang.org/rustc-builds/3d3394eb64ee2f99ad1a2b849b376220fd38263e/metrics-mingw-check.json > metrics.json
$ cargo run --manifest-path src/ci/citool/Cargo.toml postprocess-metrics metrics.json --job-name mingw-check --parent 961351c76c812e3aeb65bfb542742500a6436aed > out.md
```
r? `@marcoie`
|
|
|
|
|
|
|
|
Only use `DIST_TRY_BUILD` for try jobs that were not selected explicitly
Some CI jobs (x64 Linux, ARM64 Linux and x64 MSVC) use the `opt-dist` tool to build an optimized toolchain using PGO and BOLT. When performing a default try build for x64 Linux, in most cases we want to run perf. on that artifact. To reduce the latency of this common use-case, `opt-dist` skips building several components not needed for perf., and it also skips running post-optimization tests, when it detects that the job is executed as a try job (not a merge/auto job).
This is useful, but it also means that if you *want* to run the tests, you had to go to `jobs.yml` and manually comment this environment variable, create a WIP commit, do a try build, and then remove the WIP commit, which is annoying (in the similar way that modifying what gets run in try builds was annoying before we had the `try-job` annotations).
I thought that we could introduce some additional PR description marker like `try-job-run-tests`, but it's hard to discover that such things exist.
Instead, I think that there's a much simpler heuristic for determining whether `DIST_TRY_BUILD` should be used (that I implemented in this PR):
- If you do just ``@bors` try`, without any custom try jobs selected, `DIST_TRY_BUILD` will be activated, to finish the build as fast as possible.
- If you specify any custom try jobs, you are most likely doing experiments and you want to see if tests pass and everything builds as it should. The `DIST_TRY_BUILD` variable will thus *not* be set in this case.
In this way, if you want to run dist tests, you can just add the `try-job: dist-x86_64-linux` line to the PR description, and you don't need to create any WIP commits.
r? `@marcoieni`
|
|
|
|
|
|
|
|
|
