Conversation
This repo lacked the typical CI checks: formatting, feature-testing, etc. Here we model the workflow on oxidecomputer/iddqd (and similar libraries in our ecosystem): - RUSTFLAGS: -D warnings across every job, RUSTDOCFLAGS for the doc build - a lint job running rustfmt, clippy over the feature powerset via cargo-hack, and rustdoc - the powerset build and test on one runner, since a feature combination that breaks does so identically everywhere, with a separate pass for doctests, which nextest does not run - macOS covered at two feature points instead, for platform rather than configuration breadth - nextest as the runner, as omicron, maghemite, and iddqd use, pinned by .config/nextest.toml in the omicron style, with required and recommended in sync with the buildomat pin - MSRV moved out of the build matrix into its own job - SHA-pinned actions and Swatinem/rust-cache We also add an illumos job, running on buildomat.
oxnet has carried configuraitons for both (depend-a)bots, where only dependabot has ever run. Every other Rust repo in our org is renovate-only. Here, we drop dependabot.yml to follow other repos and avoid overlap once renovate is switched on for this repo.
|
Happy to take a look; what's the motivation for each of these changes? |
Mainly, some consistency with our other libraries. On renovate, well, I feel like that's our standard, no? |
Makes sense. With regard to other types, I think the mandate of the crate is to keep it to things that are very unlikely to change e.g. because they're well established industry concepts or are specified by some unchanging RFC.
I don't think so? But maybe? Can we leave dependabot since I mostly deal with the dependencies? Also: nextest and cargo-hack? |
Sure, but I think we're trying to use oxnet to make types consistent across various projects now (maghemite, dendrite, omicron as examples), so we'll see more types enter here for consistency across domains.
Sure, but should we settle on one or the other? I saw both configurations here?
Nextest mainly cause that's the defactor for illumos work, but I can remove it. On hack, that was geared toward the feature powerset work, but I can remove that too (for sure). That was mostly toward other lib consistency. |
I can't tell if that's like "sure, that was the plan, but there's a new plan" or "sure, these types conform to those existing expectations."
dependabot
Whatever you think. |
I meant that we'll be trying to generalize more in this repo, so we'll see more types enter the fray. However, I know that we need to be careful how we update the code here, because it's a dep for so many projects.
+1.
+1 (then I'll keep these). |
Based on discussion with @ahl, we want to keep dependabot, and focus the feature testing where possible.
zeeshanlakhani
changed the title
|
@ahl updated. |
2 participants
oxnet has been lacking on the CI-side compared to some of the other Rust libs in our GH org, e.g., rustfmt and clippy checks, a rustdoc build, illumos-runs on buildomat, etc.
This also allows PRs built atop other PRs to run the suite.