-
Notifications
You must be signed in to change notification settings - Fork 1.1k
illumos: add CI using Buildomat #4172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
r? @JohnTitor rustbot has assigned @JohnTitor. Use |
Add continuous integration for the x86_64-unknown-illumos target using the [buildomat] CI service, and fix up issues such that CI passes. ## What is buildomat? Buildomat is a CI service, similar in spirit to services like GitHub Actions. Buildomat is open source, built and maintained by us at Oxide, and is used by our own CI. Here's an example run with this PR: * [GitHub](https://github.com/sunshowers/libc/runs/33879292394) * [Buildomat](https://buildomat.eng.oxide.computer/wg/0/details/01JE79XGDC2N4VB80001F6T20Y/S6TwO6zHQJn0YdrmL6jTMx7b2IhpDb1fa5cLcGHX6eetNyS8/01JE79XW5Z6VCXEZ02FXPWYMCY) As part of this, at Oxide we're committing to maintaining the buildomat support. This includes: * Providing compute resources. * Maintaining and fixing issues in a timely manner. In order to have buildomat CI working, the rust-lang project would need to [install the buildomat app] (allowlisted to libc if desired). ## Why another CI system? The main alternative to buildomat would be something like [vmactions]. While vmactions provides an OmniOS build, OmniOS is actually a downstream distribution of illumos that includes several APIs not present in illumos. For example, OmniOS has an [inotify implementation] but upstream illumos doesn't. It would be easy to accidentally add inotify APIs to libc even though that wouldn't build on other illumos distributions. More importantly, at Oxide we don't feel confident providing support for a third-party service. We'd like to not just throw CI support over the wall but instead are committed to the long-term health of Rust on illumos. Since we use Buildomat ourselves, we're strongly incentivized to maintain it in a way that wouldn't be true for other solutions. [Buildomat]: https://github.com/oxidecomputer/buildomat [install the buildomat app]: https://github.com/apps/buildomat [vmactions]: https://github.com/vmactions [inotify implementation]: https://man.omnios.org/7/inotify
dbc89f4
to
1a9b96f
Compare
I have no objection to this as a non-blocking job, but it needs infra signoff. Link to the existing Zulip stream https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Buildomat.20app.20for.20.60libc.60 @rustbot blocked |
(Rebase and re-do of #4023, which was inadvertently closed. This time the PR is against a branch of mine, not main in my repo, so hopefully this won't happen again.)
Add continuous integration for the x86_64-unknown-illumos target using the buildomat CI service, and fix up issues such that CI passes.
What is buildomat?
Buildomat is a CI service, similar in spirit to services like GitHub Actions. Buildomat is open source, built and maintained by us at Oxide, and is used by our own CI.
Here's an example run with this PR:
As part of this, at Oxide we're committing to maintaining the buildomat support. This includes:
In order to have buildomat CI working, the rust-lang project would need to install the buildomat app (allowlisted to libc if desired).
Why another CI system?
The main alternative to buildomat would be something like vmactions.
While vmactions provides an OmniOS build, OmniOS is actually a downstream distribution of illumos that includes several APIs not present in illumos. For example, OmniOS has an inotify implementation but upstream illumos doesn't. It would be easy to accidentally add inotify APIs to libc even though that wouldn't build on other illumos distributions.
More importantly, at Oxide we don't feel confident providing support for a third-party service. We'd like to not just throw CI support over the wall but instead are committed to the long-term health of Rust on illumos. Since we use Buildomat ourselves, we're strongly incentivized to maintain it in a way that wouldn't be true for other solutions.