illumos: add CI using Buildomat #4172
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
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
sunshowers
force-pushed
the
illumos-test
branch
from
dbc89f4
to
1a9b96f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(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.