Community-supported build slaves for 2nd tier platforms

tools and infrastructure
1

Over the years we have been reluctant to officially support more platforms than Linux/Windows/Mac, though we currently provide some guarantees about Android as well. FreeBSD has been 2nd tier for a long time, but has miraculously continued to build.

Anybody who has ported Rust knows how hard it is to keep Rust building is it evolves, and there have been quite a few ports of Rust recently landing in-tree.

We’ve had a few requests recently from people who want to provide their own build slaves for 2nd tier platforms, and this should be possible with just a bit of effort. In turn for providing the buildslaves, we can probably offer 2 things in the near term:

  • Non-gated testing on the ‘auto’ integration branches. Non-gated meaning that bors will not care whether your tests pass or fail.
  • snapshot builds and uploads. Maintainers though will not be required to keep 2nd tier snapshots working.

This gives the platform maintainers the tools to help them keep up, but hopefully doesn’t require any new effort from other project developers.

Not sure what kind of feedback I’m looking for here, though if you want to donate a buildslave and be the maintainer of a currently-unmaintained platform I’d definitely love to hear from you to gauge interest.

cc @alexcrichton @dhuseby

1 Like
2

@brson I think it would be good if bors accepted an explicit override for merging despite failing on second tier platforms instead of that being the default.

3

I wrote some really simplistic notes about setting up a buildslave: https://github.com/rust-lang/rust-buildbot#slave-configuration

4

I’m very interested in contributing to the FreeBSD maintenance effort. At the moment I’m setting up a nightly build that includes make check, so there are a few gdb-related tests to change or ignore.

I was planning to publish the nightly builds on my own infrastructure, but it would be much better to make them available via official channels if possible.

5

This thread just reminds me of https://github.com/rust-lang/rust-buildbot/issues/2

6

I've been building/hosting unofficial rust and cargo nightlies for arm-unknown-linux-gnueabihf for almost 2 weeks now. Note that I'm not gating the uploads on the success of make check because some tests are failing and I can't commit to fixing them right now. However, I still run the test suite and upload the full logs, so at least potential contributors can tell what needs fixing.

I'd be interested in providing my ARM board as a buildbot slave. However,

I don't think this is a good idea in my case, because build+test time for rustc in my quad core ARM device is 6h+. Even if bors doesn't gate on the success of my ARM build, it would still have to wait for it to finish, right? That would greatly increase test cycle time.

But, I could hook my buildbot slave to the snapshot and nightly triggers. Which would be very similar to what I'm doing now, except that it would ensure that my nightlies are built at the same commit hash as the official ones are. Right now my builds are time based, so they may not always match the official ones (haven't seen that happen so far).

About distribution via rustup/multirust. I think we should put the unofficial nightlies behing an --unofficial flag to let the users know that they are opting in to non officially supported target:

# On some ARM device
$ ./rustup
The `arm-unknown-linux-gnueabihf` is not an officially supported triple, however, there are unofficial nightlies in stock. You can opt-in by passing the `--unofficial` flag. Be warned that these nightlies may break from time to time (..)
$ ./rustup --unofficial
# Proceed with install

Or not use the flag, and simply add a warning message telling the users that they are using an unofficial nightly. But, I think it's easy to miss the message with this alternative approach.

Another thing I'd like to see is some help for cross-compilation. Since compilation times are rather bad on some ARM devices (6 seconds to compile "Hello, world!" on a single core ARM device), some people have requested information on how to set up cross-compilation. I wrote a guide about the topic, and I think rustup/multirust could provide some help in this area.

What I have in mind is a --target=$TRIPLE flag that would download the nightly for $TRIPLE and install the cross compiled crates (.rlibs) in the native installation. At the very least this should let you easily cross-compile static libraries. Cross compiling binaries or crates with C dependencies additionally require a cross-compiler for linking and cross-compiled C libraries (libc, libgcc_s, etc), but, I don't think we can provide much help for these other scenarios.

7

@wgr It would be great if we could distribute community-built nightlies as part of our infrastructure.

To do that we would need to add slaves just for the 2nd-tier dist builds and adjust the buildbot code to allow 2nd-tier dist builds to fail.

8

I think bors will proceed once all the builds it cares about have finished, but even so it might cause problems with the queue of arm builds growing forever. The existing non-operational bitrig slave has a similar problem in that it's just accumulating build requests.

Perhaps the old integration build requests can be pruned periodically.

Hooking into nightlies is also what @wgr asked for, but it isn't what I have set up yet. I agree though it's the logical next step for 2nd-tier support.

Agree that making sure they are explicitly 'unofficial' is probably important.

I have similar ideas about improving cross compile support. The next action item I have there is to split the target libs into their own installation component.

9

I was able to get a Bitrig build slave configured and running. The builds are happening but it is failing in the configure of llvm because the rust fork of llvm hasn’t cherry-picked my upstreamed patch to llvm. Once that gets merged, the build phase will work. I have been manually building snapshots of auto-bitrig-64-opt and have pushed them to github. What’s the easiest way for me to get the most recent snapshot included on the snapshot server? According to the latest snapshots.txt file, the most recent snapshot revision was 880fb89. Here is the bitrig-64 version of it.

–dave

10

@dhuseby I will upload your bitrig snapshot tomorrow. So glad you got the buildslave working!

11

@dhuseby The initial bitrig snap is uploaded!

12

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.