about summary refs log tree commit diff
path: root/src/ci/docker
AgeCommit message (Collapse)AuthorLines
2019-03-01Update toolchain to build NetBSD releaseAlex Crichton-24/+8
This allows us to remove the "allow old toolchains" flag we pass to LLVM, ensuring that we'll be up to date when LLVM needs us to be!
2019-02-27Introduce assembly testsDenys Zariaiev-1/+2
2019-02-27Whitelist containers that allow older toolchainsAlex Crichton-1/+2
We'll use this as a temporary measure to get an LLVM update landed, but we'll have to go through and update images later to make sure they've got the right toolchains.
2019-02-23Added a connection timeout and speed threshold when downloading the Docker cachekennytm-1/+1
2019-02-18Auto merge of #58549 - pietroalbini:fix-docker-ci-hash, r=Mark-Simulacrumbors-3/+3
ci: fix docker cache hash collision #58416 uncovered a bug in our caching for docker images: if the image `foo` pulls files from the image `bar` and a file in `bar` changed, the hash of `foo` will be the same even though it should be different. In that PR's case, `dist-i686-linux` pulls scripts from `dist-x86_64-linux`, and the PR only changed those scripts, causing an hash collision for `dist-i686-linux`. We have to fix this, since the image will be rebuilt every time bors switches from testing master to testing beta/stable (and when it switches back), making CI way more painful than it currently is. The approach used by this PR is to just include all the files in `src/ci/docker` in the hash. It's a bit heavy-handed and it will cause a rebuild of all the images every time a single image changes, but it's the best I can think of. r? @Mark-Simulacrum cc @alexcrichton @kennytm
2019-02-18ci: fix docker cache hash collisionPietro Albini-3/+3
Before this commit the hash used to cache docker images was calculated from the image's files and the files in the scripts/ directory. This worked fine when all the files used by an image were in those directories, but some images pull files from other images, causing hash collisions in some cases. This commit changes the hash to include the files of all the docker images, causing a rebuild of all the images when a single one changes. That's a bit heavy-handed, but we have no way to track which files an image pulls in and hash collisions are really painful to deal with.
2019-02-17Auto merge of #58416 - cuviper:dist-linux-gcc, r=alexcrichtonbors-111/+312
[CI] Update GCC in the dist-linux builders Upstream LLVM is planning to raise their minimum toolchain requirements, so they may start using C++14 features. This new policy has already landed in the form of a "soft" error. http://lists.llvm.org/pipermail/llvm-dev/2019-February/130117.html For GCC, they will require at least version 5.1. This PR moves our crosstool-ng builders to their max GCC 5.2, with a few small patches to fix compatibility. The dist-x86_64-linux builder is updated to GCC 5.5 and LLVM/Clang 8.0.0-rc2, which also affects dist-i686-linux sharing the same scripts. r? @alexcrichton
2019-02-15Auto merge of #58406 - Disasm:rv64-support, r=nagisabors-0/+2
Add riscv64{imac,gc}-unknown-none-elf targets Previous attempt by @fintelia: https://github.com/rust-lang/rust/pull/58012 Related: https://github.com/rust-embedded/wg/issues/218
2019-02-12[CI] Update dist-x86_64-linux to GCC 5.5Josh Stone-22/+12
This also updates dist-i686-linux, since it borrows the same scripts. While we're at it, update llvm+clang+lld to llvm-project 8.0.0-rc2.
2019-02-12[CI] Update crosstool-ng builders to GCC 5.2Josh Stone-89/+300
2019-02-12Add riscv64gc-unknown-none-elf targetVadim Kaushan-0/+1
2019-02-12Add riscv64imac-unknown-none-elf targetVadim Kaushan-0/+1
2019-02-12use Ubuntu keyserver for CloudABI portsAndy Russell-5/+4
The Ubuntu keyserver is more reliable than the MIT PGP server, which is prone to going down. This commit also explicitly uses port 80 on the keyserver for reasons outlined in #57844.
2019-02-04Add embedded bookJames Munns-0/+1
2019-02-01Auto merge of #57937 - denzp:nvptx, r=nagisabors-5/+15
NVPTX target specification This change adds a built-in `nvptx64-nvidia-cuda` GPGPU no-std target specification and a basic PTX assembly smoke tests. The approach is taken here and the target spec is based on `ptx-linker`, a project started about 1.5 years ago. Key feature: bitcode object files being linked with LTO into the final module on the linker's side. Prior to this change, the linker used a `ld` linker-flavor, but I think, having the special CLI convention is a more reliable way. Questions about further progress on reliable CUDA workflow with Rust: 1. Is it possible to create a test suite `codegen-asm` to verify end-to-end integration with LLVM backend? 1. How would it be better to organise no-std `compile-fail` tests: add `#![no_std]` where possible and mark others as `ignore-nvptx` directive, or alternatively, introduce `compile-fail-no-std` test suite? 1. Can we have the `ptx-linker` eventually be integrated as `rls` or `clippy`? Hopefully, this should allow to statically link against LLVM used in Rust and get rid of the [current hacky solution](https://github.com/denzp/rustc-llvm-proxy). 1. Am I missing some methods from `rustc_codegen_ssa::back::linker::Linker` that can be useful for bitcode-only linking? Currently, there are no major public CUDA projects written in Rust I'm aware of, but I'm expecting to have a built-in target will create a solid foundation for further experiments and awesome crates. Related to #38789 Fixes #38787 Fixes #38786
2019-01-31Auto merge of #57914 - jethrogb:jb/sgx-unwind-version, r=alexcrichtonbors-22/+30
SGX target: clean up dist builder, update libunwind This incorporates https://github.com/fortanix/llvm-project/pull/4 Fixes https://github.com/fortanix/rust-sgx/issues/65 r? @alexcrichton
2019-01-31Updated commit id for building libunwind.Vardhan Thigle-2/+2
2019-01-31Auto merge of #57514 - michaelwoerister:xlto-tests, r=alexcrichtonbors-4/+23
compiletest: Support opt-in Clang-based run-make tests and use them for testing xLTO. Some cross-language run-make tests need a Clang compiler that matches the LLVM version of `rustc`. Since such a compiler usually isn't available these tests (marked with the `needs-matching-clang` directive) are ignored by default. For some CI jobs we do need these tests to run unconditionally though. In order to support this a `--force-clang-based-tests` flag is added to compiletest. If this flag is specified, `compiletest` will fail if it can't detect an appropriate version of Clang. @rust-lang/infra The PR doesn't yet enable the tests yet. Do you have any recommendation for which jobs to enable them? cc #57438 r? @alexcrichton
2019-01-30CI: Use lld for linking LLVM in the x86_64-gnu-debug image.Michael Woerister-0/+1
2019-01-30ci: Use clang as the C++ compiler for x86_64-gnu-debug.Michael Woerister-3/+9
2019-01-30Add missing packages.Michael Woerister-0/+5
2019-01-29Use correct CI test image for WASM and NVPTXDenys Zariaiev-18/+0
2019-01-29Provide PTXLinker with fallback to internal `target-cpu`Denys Zariaiev-1/+1
2019-01-29Merge NVPTX and WASM test images into `test-various`Denys Zariaiev-5/+14
2019-01-29Auto merge of #57862 - hsivonen:buildneon, r=alexcrichtonbors-2/+6
Build the standard library for thumbv7neon-unknown-linux-gnueabihf in CI Using the `dist-armv7-linux` image instead of `dist-various-1` in order to use the ARMv7 toolchain available in `dist-armv7-linux`. Closes #57030.
2019-01-28Adjust PTXLinker LTO logic and CLIDenys Zariaiev-1/+1
2019-01-28Build the standard library for thumbv7neon-unknown-linux-gnueabihf in CIHenri Sivonen-2/+6
Closes #57030.
2019-01-28NVPTX: by-default use target cpu "sm_30"Denys Zariaiev-1/+1
2019-01-27Enable CI for `nvptx64-nvidia-cuda`Denys Zariaiev-0/+19
2019-01-26Update SGX libunwindJethro Beekman-1/+1
2019-01-26Clean up build-x86_64-fortanix-unknown-sgx-toolchain.shJethro Beekman-20/+28
2019-01-24Rollup merge of #57803 - jethrogb:jb/sgx-unwind-version, r=alexcrichtonMazdak Farrokhzad-1/+1
Several changes to libunwind for SGX target Two fixes: * #34978 bites again! * __rust_alloc are actually private symbols. Add new public versions. Also, these ones are `extern "C"`. Upstream changes (https://github.com/fortanix/llvm-project/pull/2, https://github.com/fortanix/llvm-project/pull/3): * b7357de Avoid too new relocation types being emitted * 0feefe5 Use new symbol names to call Rust allocator Fixes https://github.com/fortanix/rust-sgx/issues/65
2019-01-24Enable Clang-based tests on x86_64-gnu-debug builder.Michael Woerister-1/+8
2019-01-24Rollup merge of #57844 - euclio:keyserver-port, r=alexcrichtonMazdak Farrokhzad-1/+1
use port 80 for retrieving GPG key This works around firewalls blocking port 11371. See https://unix.stackexchange.com/questions/75892/keyserver-timed-out-when-trying-to-add-a-gpg-public-key.
2019-01-23make sure to accept all android licensesPietro Albini-1/+1
2019-01-22use port 80 for retrieving GPG keyAndy Russell-1/+1
This works around firewalls blocking port 11371. See https://unix.stackexchange.com/questions/75892/keyserver-timed-out-when-trying-to-add-a-gpg-public-key.
2019-01-21Update libunwind for SGX targetJethro Beekman-1/+1
2019-01-15Auto merge of #57130 - ↵bors-0/+82
VardhanThigle:Vardhan/x86_64-fortanix-unknown-sgx-tier2_support, r=alexcrichton Upgrade x86_64-fortanix-unknown-sgx platform support to tier 2 ## Overview 1. This PR upgrades x86_64-fortanix-unknown-sgx platform support to tier 2 (std only) by setting up build automation for this target. 1. For supporting unwinding, this target needs to link to a port of LLVM's libunwind (more details could be found in #56979), which will be distributed along with the Rust binaries (similar to the extra musl objects) ### Building and copying libunwind: We have added a new build script (`build-x86_64-fortanix-unknown-sgx-toolchain.sh`) that will run while the container is built. This will build `libunwind.a` from git source. While the container is built, the persistent volumes where obj/ gets created aren't yet mapped. As a workaround, we copy the built `libunwind.a` to `obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-fortanix-unknown-sgx/lib/` after x.py runs. If any reviewer knows of a better solution, please do tell. r? @Mark-Simulacrum
2019-01-13Adding Build automation for x86_64-fortanix-unknown-sgxVardhan Thigle-0/+82
2019-01-09Replace Arm GCC to a more recent versionHugues de Valon-2/+8
The version included in Ubuntu 16.04 repositories in the dist-various-1 docker, Arm GCC version 4.9, does not support the new Armv8-M architecture. This commit adds the team-gcc-arm-embedded PPA to get through APT a newer version of Arm GCC.
2019-01-09Add dist builder for Armv8-M MainlineHugues de Valon-0/+1
This commit adds the Armv8-M Mainline target in the list of targets that get their dist components built. It also update the build-manifest so that this target gets also its dist components uploaded.
2019-01-03ci: Upgrade Travis to XenialAlex Crichton-3/+5
In theory we shouldn't require trusty so long as docker continues to work!
2018-12-25Remove licensesMark Rousskov-507/+0
2018-12-24Rollup merge of #57010 - phansch:run_compiletest_tests_on_ci, r=kennytmMazdak Farrokhzad-1/+2
Actually run compiletest tests on CI I was assuming that https://github.com/rust-lang/rust/pull/56792 would have resulted in compiletest tests being executed on CI. However, I couldn't find any mentions of the unit test names in any CI logs. This adds the compiletest test execution to the checktools.sh script.
2018-12-23Auto merge of #56892 - alexcrichton:new-llvm, r=michaelwoeristerbors-17/+14
rustc: Update Clang used to build LLVM on Linux This commit updates from LLVM 7.0.0 to git revisions of clang/llvm/lld to build LLVM on our dist builders for Linux. The goal of this is to fix #56849 by picking up a fix [1] in LLD. Closes #56849 [1]: https://github.com/llvm-mirror/lld/commit/3be4e82db78b46a8ca349b2b799dec620a6f159f
2018-12-20Move compiletest test run to mingw-check builderPhilipp Hansch-6/+2
This way, checktools.sh continues to be used only for tools that are published later on.
2018-12-20Run compiletest tests on CIPhilipp Hansch-0/+5
I was assuming that https://github.com/rust-lang/rust/pull/56792 would have resulted in compiletest tests being executed in CI. However, I couldn't find any mentions of the unit test names in any CI logs. This adds the compiletest test execution to the checktools.sh script.
2018-12-19Rollup merge of #56947 - hsivonen:neon, r=alexcrichtonPietro Albini-0/+2
Add targets thumbv7neon-linux-androideabi and thumbv7neon-unknown-linux-gnueabihf These two targets enable both thumb-mode and NEON for ARMv7 CPUs. This another attempt at #49902, which cannot be reopened. Between that PR and this one, some subrepos with C code whose build systems were failing went away.
2018-12-17Auto merge of #56642 - nikic:llvm-6, r=alexcrichtonbors-2/+2
Bump minimum required LLVM version to 6.0 Based on the discussion in #55842, while the overall position of Rust wrt LLVM continues to be contentious, there does seem to be a consensus that there is no need for continued support of LLVM 5. This PR bumps our version requirement to LLVM 6.0 and makes Travis run against that. I hope that this is going to unblock #52694. If I understand correctly, while this issue still exists in LLVM 6, Ubuntu has backported the relevant patch. r? @alexcrichton
2018-12-16rustc: Update Clang used to build LLVM on LInuxAlex Crichton-17/+14
This commit updates from LLVM 7.0.0 to git revisions of clang/llvm/lld to build LLVM on our dist builders for Linux. The goal of this is to fix #56849 by picking up a fix [1] in LLD. Closes #56849 [1]: https://github.com/llvm-mirror/lld/commit/3be4e82db78b46a8ca349b2b799dec620a6f159f
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 00:20:36 +0000