-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
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 |
|
Following up here: I am not opposed to this from a feedback perspective, as long as it's an optional job. You'll need to figure out the details on Zulip with the infra team though. I know they tend to prefer solutions that work through Github Actions (e.g. the recent PowerPC/s390x runners https://community.ibm.com/community/user/blogs/gerrit-huizenga/2024/03/06/github-actions-runner-for-ibm-power-and-linuxone) |
|
Not really blocked I suppose |
|
Reminder, once the PR becomes ready for a review, use |
|
This has been inactive for a little while, so I am going to close it. I'd appreciate an optional Illumos job to help make sure we don't accidentally break you, but if that's only possible with a new app then there are infra concerns that need to be figured out. @sunshowers please feel free to reopen if you follow up with the infra team and get the app installed or have an alternative. (FYI @jclulow @pfmooney in case one of you would like to do the followup here.) |
|
Thanks @tgross35 -- will follow up when we next have time. |
(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.