about summary refs log tree commit diff
path: root/src/ci/docker
AgeCommit message (Collapse)AuthorLines
2024-09-17Add zlib to musl dist image so rust-lld will support zlib compression for ↵Kyle Huey-0/+1
debug info there. Fixes #130063.
2024-09-14Auto merge of #129974 - cuviper:ci-llvm-19, r=Mark-Simulacrumbors-0/+62
ci: add a runner for vanilla LLVM 19 Ubuntu 24.10 has `llvm-19` packages that we can start testing with. The `Dockerfile` is otherwise the same as the `llvm-18` runner.
2024-09-07Fix bash syntaxChris Denton-1/+1
2024-09-07Fix checktools.sh non-msvc buildsChris Denton-4/+7
2024-09-07Split x86_64-msvc-ext into two jobsChris Denton-5/+7
2024-09-05Rollup merge of #128928 - ojeda:ci-rfl-more-tools, r=KobzolMatthias Krüger-7/+43
CI: rfl: add more tools and steps This will add some time for the tool building -- the actual steps should be quick, though, and allows us to cover quite a few more tools and unstable features in use. Please see the individual commits for a few details. Cc: `@GuillaumeGomez` `@tgross35` r? `@Kobzol` try-job: x86_64-rust-for-linux
2024-09-05Rollup merge of #101339 - the8472:ci-randomize-debug, r=Mark-SimulacrumMatthias Krüger-0/+1
enable -Zrandomize-layout in debug CI builds This builds rustc/libs/tools with `-Zrandomize-layout` on *-debug CI runners. Only a handful of tests and asserts break with that enabled, which is promising. One test was fixable, the rest is dealt with by disabling them through new cargo features or compiletest directives. The config.toml flag `rust.randomize-layout` defaults to false, so it has to be explicitly enabled for now.
2024-09-04ci: add a runner for vanilla LLVM 19Josh Stone-0/+62
2024-09-04Auto merge of #129356 - nikic:llvm19-host, r=Mark-Simulacrumbors-1/+2
Update x86_64-linux host compiler to LLVM 19 rc 3
2024-08-31enable layout randomization in x86_64-gnu-llvm-17 CI jobThe 8472-0/+1
2024-08-28CI: rfl: factor out build targetsMiguel Ojeda-8/+9
It will make it easier to add more in the future. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-28CI: rfl: add macro expanded source build (`-Zunpretty=expanded`)Miguel Ojeda-0/+8
This particular target does not expand into much code, so it is a good first candidate to see if we could keep this in the CI. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-28CI: rfl: add a `rustfmt` runMiguel Ojeda-2/+9
This change will also remove the current warnings in the build due to `rustfmt` not being available (for `bindgen` output): error: 'rustfmt' is not installed for the custom toolchain 'local'. note: this is a custom toolchain, which cannot use `rustup component add` help: if you built this toolchain from source, and used `rustup toolchain link`, then you may be able to build the component with `x.py` Failed to run rustfmt: Internal rustfmt error (non-fatal, continuing) Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-28CI: rfl: add a Clippy buildMiguel Ojeda-2/+13
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-28CI: rfl: switch to a stage 2 buildMiguel Ojeda-2/+2
Apparently tools like `rustfmt` require it in order to find the right `librustc_driver.so` without extra tweaks. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-28CI: rfl: add a couple comments to split the steps and document themMiguel Ojeda-0/+9
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-27Rollup merge of #128935 - lqd:needs-zstd, r=KobzolTrevor Gross-4/+5
More work on `zstd` compression r? ``@Kobzol`` as we've discussed this. This is a draft to show the current approach of supporting zstd in compiletest, and making the tests using it unconditional. Knowing whether llvm/lld was built with `LLVM_ENABLE_ZSTD` is quite hard, so there are two strategies. There are details in the code, and we can discuss this approach. Until we know the config used to build CI artifacts, it seems our options are somewhat limited in any case. zlib compression seems always enabled, so we only check this in its dedicated test, allowing the test to ignore errors due to zstd not being supported. The zstd test is made unconditional in what it tests, by relying on `needs-llvm-zstd` to be ignored when `llvm.libzstd` isn't enabled in `config.toml`. try-job: x86_64-gnu try-job: x86_64-msvc try-job: x86_64-gnu-distcheck
2024-08-25enable `llvm.libzstd` on test x64 linux builderRémy Rakic-1/+2
2024-08-25move and rename zstd scriptRémy Rakic-3/+3
move it where it's used, and name it like the other scripts
2024-08-23CI: rfl: move to temporary commitMiguel Ojeda-2/+2
Link: https://github.com/rust-lang/rust/pull/129416 Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-21Update x86_64-linux host compiler to LLVM 19 rc 3Nikita Popov-1/+2
2024-08-19Auto merge of #128722 - tgross35:new-resolver-root, r=Mark-Simulacrumbors-1/+1
Switch to using the v2 resolver in most workspaces Pinning the resolver to v1 was done in 5abff3753a7c ("Explicit set workspace.resolver ...") in order to suppress warnings. Since there is no specific reason not to use the new resolver and since it fixes issues, change to `resolver = "2"` everywhere except library.
2024-08-18Rollup merge of #129048 - heiher:update-crosstool-loongarch64, r=Mark-SimulacrumTrevor Gross-7/+7
Update `crosstool-ng` for loongarch64 The current cross-compilation toolchain for the LoongArch64 target consists of GCC 13.2.0, Binutils 2.40, and Glibc 2.36. However, Binutils 2.40 has known issues that in broken binaries without any error reports: - https://github.com/rust-lang/rust/issues/121289 - https://github.com/cross-rs/cross/issues/1538 This patch upgrades the cross-compilation toolchain for the LoongArch64 target to resolve these issues. - GCC: 13.2.0 -> 14.2.0 - Binutils: 2.40 -> 2.42 The new binaries remain compatible with the existing GCC 13.2.0/Glibc 2.36 distribution, and no issues have been identified. try-job: dist-loongarch64-linux
2024-08-18Switch to using the v2 resolver in most workspacesTrevor Gross-1/+1
Pinning the resolver to v1 was done in 5abff3753a7c ("Explicit set workspace.resolver ...") in order to suppress warnings. Since there is no specific reason not to use the new resolver and since it fixes issues, change to `resolver = "2"` everywhere except library and submodules.
2024-08-13Update `crosstool-ng` for loongarch64WANG Rui-7/+7
The current cross-compilation toolchain for the LoongArch64 target consists of GCC 13.2.0, Binutils 2.40, and Glibc 2.36. However, Binutils 2.40 has known issues that in broken binaries without any error reports: - https://github.com/rust-lang/rust/issues/121289 - https://github.com/cross-rs/cross/issues/1538 This patch upgrades the cross-compilation toolchain for the LoongArch64 target to resolve these issues. - GCC: 13.2.0 -> 14.2.0 - Binutils: 2.40 -> 2.42 The new binaries remain compatible with the existing GCC 13.2.0/Glibc 2.36 distribution, and no issues have been identified.
2024-08-12don't use `--rustc-args` to test the stdlib's size optimizations featureRémy Rakic-3/+3
2024-08-09Install zstd in dist builder image.Kyle Huey-0/+33
Build libzstd from source because the EPEL package is built without fPIC.
2024-08-09Add zlib and zstd dev packages for building lld.Kyle Huey-0/+2
2024-08-09Enable zstd for debug compression.Kyle Huey-0/+1
Set LLVM_ENABLE_ZSTD alongside LLVM_ENABLE_ZLIB so that --compress-debug-sections=zstd is an option. Use static linking to avoid a new runtime dependency. Add an llvm.libzstd bootstrap option for LLVM with zstd. Set it off by default except for the dist builder. Handle llvm-config --system-libs output that contains static libraries.
2024-08-07Fuchsia Test Runner: enable ffx repository serverJeff Martin-0/+13
The default repository server setting has changed on Fuchsia (default is newly "false"). Now, in order to start the repository server, the config `repository.server.enabled` must be set to true.
2024-08-03Promote riscv64gc-unknown-linux-musl to tier 2Amanieu d'Antras-2/+12
2024-07-29CI: rfl: build the documentationMiguel Ojeda-0/+3
Since the `rfl` CI job has not had almost any issue for some weeks, it is a good time to try to increase a bit the scope of what it tests. The kernel does not use any particular `rustdoc` unstable issue (apart from the doctests ones) so far, so in principle it should not introduce extra issues here, and may be a good extra test case for Rust. In addition, it may help to test new unstable features in the future. In the worst case, we can revert it. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-29CI: rfl: build the generated doctestsMiguel Ojeda-1/+2
We were already generating the doctests, which should already catch most issues with our hack around `--test-builder` and `--no-run`. However, we were not building the result of that transformation, thus build it for completeness and to ensure the hack may not have produced something completely broken. In the worst case, we can revert it. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-29Rollup merge of #128322 - ojeda:rfl-ci-update, r=KobzolMatthias Krüger-1/+1
CI: move RFL job forward to v6.11-rc1 The tag has been released today, and since the original hash we had in the Rust CI (which was ~v6.10-rc1), we have accumulated a fair amount of changes and new code. In particular, v6.11-rc1 is the first Linux tag where the kernel is supporting an actual minimum Rust version (1.78.0), rather than a single version. --- Let's try to do the move independently first. r? ``@Kobzol`` try-job: x86_64-rust-for-linux
2024-07-29CI: move RFL job forward to v6.11-rc1Miguel Ojeda-1/+1
The tag has been released today, and since the original hash we had in the Rust CI (which was ~v6.10-rc1), we have accumulated a fair amount of changes and new code. In particular, v6.11-rc1 is the first Linux tag where the kernel is supporting an actual minimum Rust version (1.78.0), rather than a single version. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-29Reformat `use` declarations.Nicholas Nethercote-0/+1
The previous commit updated `rustfmt.toml` appropriately. This commit is the outcome of running `x fmt --all` with the new formatting options.
2024-07-26Update Android testing to API 21, matching NDK 26Matthew Maurer-6/+6
We were running testing on API 18, which was already out of support for NDK 25, and some of the ancient behavior in that image was causing trouble when developing `rustc` features (#120326). Update to the current LTS NDK 26, and to its minimum supported API 21. Fixes: #120567
2024-07-23Bump FuchsiaTyler Mandry-1/+1
This includes changes to unblock merging #126024.
2024-07-22Rollup merge of #127923 - ferrocene:use-reuse-tool-4.0, r=pietroalbiniTrevor Gross-57/+81
Use reuse tool 4.0 This change upgrades us to reuse-tool 4.0.3, which has a new TOML format configuration instead of the old `.reuse/dep5` Debian-style file. * Updated requirements file to install reuse-4.0.3 * Ran `reuse convert-dep5` to switch to new file format * Switched over to `override` so the `REUSE.toml` file takes precedence over whatever random Copyright strings `reuse` finds in the source tree. Should fix https://github.com/rust-lang/rust/issues/127361
2024-07-22Rollup merge of #127977 - alexcrichton:update-wasi-sdk, r=Mark-Simulacrum许杰友 Jieyou Xu (Joe)-4/+4
Update wasi-sdk in CI to latest release This commit updates the `wasi-sdk` download used by the `wasm32-wasi*` targets. The motivation for this commit is generally just "keep things up to date" and is not intended to cause any issues or differences from before, just a routine update.
2024-07-22Regenerated hashes using python3.10Jonathan Pallant-1/+1
) brew install python@3.10 ) python3.10 -m venv /tmp/myenv ) source /tmp/myenv/bin/activate ) pip install pip-tools ) /tmp/myenv/bin/pip-compile --allow-unsafe --generate-hashes reuse-requirements.in
2024-07-19Update wasi-sdk in CI to latest releaseAlex Crichton-4/+4
This commit updates the `wasi-sdk` download used by the `wasm32-wasi*` targets. The motivation for this commit is generally just "keep things up to date" and is not intended to cause any issues or differences from before, just a routine update.
2024-07-19Rollup merge of #127934 - Kobzol:checktools-better-error, r=onur-ozkanMatthias Krüger-0/+4
Improve error when a compiler/library build fails in `checktools.sh` Suggested by ``@RalfJung`` [here](https://github.com/rust-lang/rust/issues/127869#issuecomment-2235829643). `x86_64-gnu-tools` should take ~45 minutes, let's see if this doesn't regress it. r? ``@onur-ozkan``
2024-07-19Improve error when a compiler/library build fails in `checktools.sh`Jakub Beránek-0/+4
2024-07-18Rollup merge of #127913 - onur-ozkan:broken-defaults, r=KobzolMatthias Krüger-0/+14
remove `debug-logging` default from tools profile `debug-logging` conflicts with `download-rustc` option, and doesn't really make sense to enable it for a profile that is used for tool development.
2024-07-18create `check-default-config-profiles.sh` for `mingw-check`onur-ozkan-2/+14
Signed-off-by: onur-ozkan <work@onurozkan.dev>
2024-07-18remove `debug-logging` default from tools profileonur-ozkan-1/+1
`debug-logging` conflicts with `download-rustc` option, and doesn't really make sense to enable it for a profile that is used for tool development. Signed-off-by: onur-ozkan <work@onurozkan.dev>
2024-07-18check default config profiles on CIonur-ozkan-0/+2
Signed-off-by: onur-ozkan <work@onurozkan.dev>
2024-07-18Upgrade to reuse 4.0.3Jonathan Pallant-58/+82
) Updated requirements file ) Ran `reuse convert-dep5` to switch to new file format
2024-07-17Rollup merge of #127828 - tgross35:docker-aarch64-uname, r=onur-ozkanTrevor Gross-4/+7
Commonize `uname -m` results for `aarch64` in docker runner `uname -m` on Linux reports `aarch64`, but on MacOS reports `arm64`. Commonize this to `aarch64`. With this fix, it is now possible to run aarch64 CI docker images on Arm MacOS.