| Age | Commit message (Collapse) | Author | Lines |
|
CI: use smaller machines in PR runs
mingw-check job-linux-16c -> job-linux-4c
~job-linux-4c 20 min in auto job
~job-linux-16c 13 min in pr job
with current pr regressed to almost 21 min, it's ok.
mingw-check-tidy job-linux-16c -> job-linux-4c small enough, so reduce to minimal
~ job-linux-16c 3 min
with current pr regressed to almost 5 min, it's ok.
x86_64-gnu-tools job-linux-16c this is top job by time in PR, so don't touch it
~ job-linux-8c 1.30 hour in auto job
~ job-linux-16c 1 hour in pr job (affected by #114613, actual time ~ 30 min)
x86_64-gnu-llvm-15 job-linux-16c don't change too
~ job-linux-8c 1.30 hour in auto job
~ job-linux-16c 30 min in pr job
Noticed while working on https://github.com/rust-lang/rust/pull/114621, so current time affected by always rebuilded docker images (but pr images always rebuilded before too, so nvm)
|
|
|
|
|
|
aarch64-msvc: remove CI hack for bad Windows SDK version
This removes hack which manually replaced windows sdk version, as it looks like useless now, as CI uses newer version: https://github.com/rust-lang-ci/rust/actions/runs/5596259246/jobs/10233070602#step:24:929
`C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\ucrt\corecrt_io.h` (look at version)
related https://github.com/rust-lang/rust/issues/88796
It's nice to have some way to assert bad version, but i don't see anything except checking env https://github.com/rust-lang/cc-rs/pull/646
|
|
|
|
See https://github.com/rust-lang-ci/rust/actions/runs/5596259246/jobs/10233070602#step:24:929 C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\ucrt\corecrt_io.h
|
|
|
|
|
|
CI: include workflow name in concurrency group
Currently, this won't change anything, because we only have one relevant workflow (`CI`), but for future proofing we should probably include the workflow name in the concurrency group.
Found by ``@klensy`` [here](https://github.com/rust-lang/rust/pull/113059#discussion_r1247213606).
|
|
CI: merge msvc cargo and tools jobs
The `x86_64-msvc-cargo` and `x86_64-msvc-tools` jobs both run for ~1 hour, but most of that time is actually spent in building LLVM and `rustc`, so I want to try merging them.

|
|
CI: merge x86_64-gnu-llvm-14 and x86_64-gnu-llvm-14-stage1 CI jobs
Another attempt to shorten CI job times. Suggested by `@the8472` [here](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/CI.20usage/near/367172221).
|
|
|
|
Currently, this won't change anything, because we only have one relevant workflow (`CI`), but for future proofing we should probably include the workflow name in the concurrency group.
|
|
Add an exception for try and try-perf branches to enable concurrent try builds and unrolled rollup builds.
|
|
Instead, only cancel them if the builds have the same commit SHA.
|
|
|
|
|
|
|
|
|
|
|
|
CI: merge `mingw` test CI jobs
Same as https://github.com/rust-lang/rust/pull/112633, but for `mingw`. From the logs it looks like the runner spends 40 minutes compiling `rustc`, and then `10`/`20` minutes running tests. It seems wasteful to split that into two jobs.
CI run: https://github.com/rust-lang/rust/actions/runs/5275702134/jobs/9541479343?pr=112645
r? `@jyn514`
|
|
|
|
Publish docs as github artifacts during CI
Discussed here: https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Building.20docs.20for.20PR.20CI
The goal is to make docs available for download after CI runs on PRs, for easy review of API changes.
Notes:
- Currently this only captures library documentation (`core`, `alloc`, `std`, `test`, `proc_macro`)
- You can't see artifacts until the entire workflow run has completed https://github.com/actions/upload-artifact/issues/53
- There is currently a generic file name `ci-artifacts`. No way to customize this based on contained files unfortunately https://github.com/actions/upload-artifact/issues/349
You can find the results at the bottom of the CI "summary" page:
<img width="379" alt="image" src="https://github.com/rust-lang/rust/assets/13724985/d3748e59-242c-40f8-9f54-82177b9b481b">
|
|
|
|
This PR saves library docs as github artifacts so they can be easily
viewed for review.
Discussed in <https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Building.20docs.20for.20PR.20CI>
|
|
|
|
Co-Authored-By: YANG Xiaojuan <yangxiaojuan@loongson.cn>
|
|
Remove `tidy` key in PR CI
This avoids confusing error messages when adding an `auto` job to CI (as recommended in the dev-guide: https://rustc-dev-guide.rust-lang.org/tests/ci.html#using-ci-to-test).
cc https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Do.20.60needs-profiler-support.60.20tests.20not.20run.20in.20CI.3F/near/355302998
r? `@ghost`
|
|
Remove aws cli install.
All runner images have the AWS CLI 2 installed, so there isn't a really strong reason to install our own version anymore.
The version we were installing was 1.27.122. The runner images currently have 2.11.x (the exact version varies by image).
I do not have the means to really test if the new version has any issues. I looked at all the `aws` commands, and none of them seem to be doing anything unusual. The page at https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.html contains a list of all the breaking changes, and I didn't see anything that looked important.
|
|
This avoids confusing error messages when adding an `auto` job to CI (as
recommended in the dev-guide: https://rustc-dev-guide.rust-lang.org/tests/ci.html#using-ci-to-test).
|
|
Optimize builder sizes
The infra-team is continuously monitoring the efficiency of the CI system in an effort to improve overall build times and resource usage. Some builders have used much less than their allocated resources, so we are testing smaller builder sizes for them.
r? `@pietroalbini`
|
|
|
|
|
|
The infra-team is continuously monitoring the efficiency of the build
system in an effort to improve overall build times and resource usage.
The builders for some of the `x86_64-gnu` targets have used much less
resources than allocated in the past, so we are testing a smaller
builder size for them.
|
|
The infra-team is continuously monitoring the efficiency of the build
system in an effort to improve overall build times and resource usage.
The builder for the `mingw-check` target have used much less resources
than allocated in the past, so we are testing a smaller builder size for
it.
|
|
The infra-team is continuously monitoring the efficiency of the build
system in an effort to improve overall build times and resource usage.
The builders for the `i686-gnu` targets have used much less resources
than allocated in the past, so we are testing a smaller builder size for
them.
|
|
|
|
Like #107044, this will let us track compatibility with LLVM 16 going
forward, especially after we eventually upgrade our own to the next.
This also drops `tidy` here and in `x86_64-gnu-llvm-15`, syncing with
that change in #106085.
|
|
These builders aren't particularly high on overall average CPU usage and finish in typically around
30 minutes. Cutting their core counts will hopefully not significantly increase wall-time while
cutting costs, allowing us to shift some of the wins into our slower builders.
|
|
This will allow moving jobs between 8 and 16 core VMs in the next commit
more easily.
|
|
Before: `CI / PR (mingw-check, false, ubuntu-20.04-16core-64gb) (pull_request)`
After: `CI / PR - mingw-check (pull_request)`
|
|
For now this keeps all the configuration identical (AFAICT) but we'll
likely want to play with the specifics to move some of the slower
builders to larger machines and the faster builders to smaller machines,
likely reducing overall usage and improving CI times.
|
|
This lead to a miscompilation in at least `char::is_whitespace` and
probably in more unknown places.....
This reverts commit 684663ed380d0e6a6e135aed9c6055ab4ba94ac8.
|
|
|
|
This reverts commit e63ec2e1402eaff949e5c53b8f6062b152010fcc.
|
|
|
|
Previously, it would only run on changes to subtrees, submodules, or select directories.
That made it so that changes to the compiler that broke tools would only be detected on a full bors merge.
This makes it so the tools builder runs by default, making it easier to catch breaking changes to clippy (which was the most effected).
|
|
Enable Cargo's sparse protocol in CI
This enables the sparse protocol in CI in order to exercise and dogfood it. This is intended test the production server in a real-world situation.
Closes #107342
|
|
This reverts commit fcbae989ae790d5b9a0a23ceba242d0b0d4e6c5b.
|
|
|