From da00dabd58f8de9ae4b6f0b1172c03667a305129 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Wed, 30 Oct 2019 21:51:23 -0400 Subject: [PATCH] ci-all-nix-prs: Draft --- rfcs/0000-ci-all-nix-prs.md | 41 +++++++++++++++++++++++-------------- 1 file changed, 26 insertions(+), 15 deletions(-) diff --git a/rfcs/0000-ci-all-nix-prs.md b/rfcs/0000-ci-all-nix-prs.md index e3d4c0864..1d399b9f7 100644 --- a/rfcs/0000-ci-all-nix-prs.md +++ b/rfcs/0000-ci-all-nix-prs.md @@ -1,7 +1,7 @@ --- -feature: (fill me in with a unique ident, my_awesome_feature) -start-date: (fill me in with today's date, YYYY-MM-DD) -author: (name of the main author) +feature: ci-all-nix-prs +start-date: 2019-10-30 +author: John Ericson (@Ericson2314) co-authors: (find a buddy later to help our with the RFC) shepherd-team: (names, to be nominated and accepted by RFC steering committee) shepherd-leader: (name to be appointed by RFC steering committee) @@ -11,39 +11,50 @@ related-issues: (will contain links to implementation PRs) # Summary [summary]: #summary -One paragraph explanation of the feature. +Build all Nix PRs in CI. +Do not merge any PR until it passes CI. # Motivation [motivation]: #motivation -Why are we doing this? What use cases does it support? What is the expected -outcome? +There is a (famous blog post)[blog-post] that everyone is sloppy and doing CI wrong. +This isn't just bad for releasing software smoothly, but also increases the burden for new contributors because it is harder to judge the correctness of PRs at a glance (is it broken? Did I break it?). +I personally find it harder to contribute, I have to worry about double checking all my work on platforms I don't have as-easy access to, like Darwin. + +We cannot yet do this for all of Nixpkgs, sadly, due to resource limits. +But, there is no reason we cannot do it for Nix itself. # Detailed design [design]: #detailed-design -This is the bulk of the RFC. Explain the design in enough detail for somebody -familiar with the ecosystem to understand, and implement. This should get -into specifics and corner-cases, and include examples of how the feature is -used. +Set up Hydra declarative jobsets to build all Nix PRs. +Those with merge access should be instructed not to merge a PR until CI passes. +Merge master into PRs or rebase before merge as a crude stop-gap to avoid master becoming an untested tree due to a merge commit. + +If Hydra gains the ability to keep master always working obviating the manual steps above beyond the PR jobs, use that ability. + +If a new CI is used, ensure that is also keeps master in an always-building state. # Drawbacks [drawbacks]: #drawbacks -Why should we *not* do this? +More process to follow. # Alternatives [alternatives]: #alternatives -What other designs have been considered? What is the impact of not doing this? +Merely build all PRs, and maintainers are still allowed to merge broken ones / not take care to avoid untested merge commits. # Unresolved questions [unresolved]: #unresolved-questions -What parts of the design are still TBD or unknowns? +Nothing. # Future work [future]: #future-work -What future work, if any, would be implied or impacted by this feature -without being directly part of the work? +- Remove the manual parts of this process. + +- Also apply to other smaller official repos, like `cabal2nix`. + +[blog-post]: https://graydon2.dreamwidth.org/1597.html