| Age | Commit message (Collapse) | Author | Lines |
|
|
|
(cherry picked from commit 036b5fcb0241c3dc28823c43b52a80376a4c040a)
|
|
|
|
To make it easier to migrate off the `rust-lang-ci/rust` repository.
(cherry picked from commit 7d32303574c63cb396d5e1cb17f00061665a0f75)
|
|
This is needed to make the cache work after moving CI from the `rust-lang-ci` org to `rust-lang`.
(cherry picked from commit eb530325f08b9151cb1917d01a8cb913ab1dd1ab)
|
|
At the moment, it seems like Windows Server 2025 20250504.1.0 is
misconfigured causing insufficient disk space failures. Temporarily go
back to Windows Server 2022 in the hope that those are not also
misconfigured.
(cherry picked from commit f4ce73ede2f4df0f9983b337ceeed96c11f52c14)
|
|
|
|
Unify sidebar buttons to use the same image
Part of https://github.com/rust-lang/rust/issues/139832.
The source sidebar looks like this with the new image:

You can test it [here](https://rustdoc.crud.net/imperio/sidebar-images/src/foo/foo.rs.html).
r? `@notriddle`
|
|
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
ci: use aws codebuild for the `dist-x86_64-linux` job
try-job: dist-x86_64-linux
|
|
ci: clean more disk space in codebuild
try-job: dist-arm-linux
|
|
|
|
uefi: Update r-efi
- Bump up the version to 5.2.0
try-job: x86_64-gnu-distcheck
try-job: x86_64-gnu
try-job: test-various
|
|
Download GCC from CI on test builders
This should reduce the duration of the `x86_64-gnu-llvm-18` job, which runs on PR CI, which is currently the only one that builds GCC (outside of the x64 dist builder).
Since we handle the GCC download in the GCC step, and not eagerly in config, we can set this flag globally across all test builders, as it won't do anything unless they actually try to build GCC.
Opening as a draft to test if it works on CI, because I still need to implement logic to avoid the download if there are any local modifications to GCC (essentially the "if-unchanged" mode, although I want to try something a bit different).
r? ```@ghost```
|
|
|
|
- Update r-efi to 5.2.0
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
CI: use aws codebuild for job dist-arm-linux
try-job: dist-arm-linux
|
|
|
|
|
|
|
|
Refactor git change detection in bootstrap
While working on https://github.com/rust-lang/rust/pull/138395, I finally found the courage to delve into the insides of git path change detection in bootstrap, which is used (amongst other things) to detect if we should rebuilt od download `[llvm|rustc|gcc]`. I found it a bit hard to understand, and given that this code was historically quite fragile, I thought that it would be better to rebuild it from scratch.
The previous approach had a bunch of limitations:
- It separated the computation of "are there local changes?" and "what upstream SHA should we use?" even though these two things are intertwined.
- It used hacks to work around what happens on CI.
- It had special cases for CI scattered throughout the codebase, rather than centralized in one place.
- It wasn't documented enough and didn't have tests for the git behavior.
The current approach should hopefully resolve all of that. I implemented a single entrypoint called `check_path_modifications` (naming bikeshed pending, half of the time I spend on this PR was thinking about names, as it's quite tricky here..) that explicitly receives a mode of operation (in CI or outside CI), and accordingly figures out that upstream SHA that we should use for downloading artifacts and it also figures out if there are any local changes. Users of this function can then use this unified output to implement `download-ci-X` and other functionality. Notably, this change detection no longer uses `git merge-base`, which makes it easier to use and doesn't require setting up remotes.
I also added a bunch of integration tests that literally spawn a git repository on disk and then check that the function can deal with various situations (PR CI, auto/try CI, local builds).
After I built this inner layer, I used it for downloading GCC, LLVM and rustc. The latter two (and especially rustc) were using the `last_modified_commit` function before, but in all cases but one this function was actually only used to check if there are any local changes, which was IMO confusing. The LLVM handling would deserve a bit of refactoring, but that's a larger change that can be done as a follow-up.
I hope that the implementation is now clear and easy to understand, so that in combination with the tests we can have more confidence that it does what we want. I tried to include a lot of documentation in the code, so I won't be repeating the actual implementation details here, if there are any questions, I'll add the answers to the documentation too :)
The new approach explicitly supports three scenarios:
- Running on PR CI, where we have one upstream bors parent commit and one PR merge commit made by GitHub.
- Running on try/auto CI, where we have one upstream bors parent commit and one PR merge commit made by bors.
- Running locally, where we assume that we have at least one upstream bors parent commit in our git history.
I removed the handling of upstreams on CI, as I think that it shouldn't be needed and I considered it to be a hack. However, it's possible that there are other use-cases that I haven't considered, so I want to ask around if people have other situations than the three use-cases described above. If there are other such use-cases, I would like to include them in the new centralized implementation and add them to the git test suite, rather than going back to the old ways :)
In particular, the code before relied on `git merge-base`, but I don't see why we can't just lookup the most recent bors commit and assume that is a merge commit that is also upstream? I might be running into Chesterton's Fence here :)
CC `@pietroalbini` To make sure that this won't break downstream users of Rust's CI.
Best reviewed commit by commit.
Companion PRs:
- For testing beta: https://github.com/rust-lang/rust/pull/138597
r? `@onur-ozkan`
Fixes: https://github.com/rust-lang/rust/issues/101907
try-job: x86_64-gnu-aux
try-job: aarch64-gnu
try-job: dist-x86_64-apple
|
|
The new git tests should be enough to check this scenario. We should ideally not be creating dummy commits on CI.
|
|
It shouldn't be needed anymore.
|
|
|
|
`assembly/asm` contained a test named `asm/aarch64-el2vmsa.rs`, while it should have been only `arch64-el2vmsa.rs`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CI: rename MacOS runner
r? ``@Kobzol``
|
|
|
|
Ubuntu 25.04 has `llvm-20` packages that we can start testing with.
The `Dockerfile` is otherwise the same as the `llvm-18`/`19` runners.
|
|
|
|
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```
|
|
r=jieyouxu,kobzol
make it possible to use stage0 libtest on compiletest
With https://github.com/rust-lang/rust/pull/119899, building the library tree will require a stage 1 compiler. This is because `compiletest` is defined as a `ToolStd` (since https://github.com/rust-lang/rust/pull/68019) in order to use the in-tree library. As a result, https://github.com/rust-lang/rust/pull/119899 makes certain development workflows more difficult as changes on the compiler tree will now require recompiling `compiletest` each time.
This PR allows switching `ToolStd` to `ToolBootstrap` with a simple boolean option in `bootstrap.toml` to allow `compiletest` to use the stage 0 `libtest` instead.
The changes under `src/ci` are clearly intended to make sure that `compiletest` doesn't break during future bootstrap beta bumps.
|
|
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>
|
|
|
|
In accordance with RFC 3771.
I also added a stub doc page for the target and renamed the
windows-gnullvm page for consistency.
|
|
This will allow us to provide links to CI workflows, jobs and summaries in the post-merge analysis report.
|
|
|