-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
nixos/*: split docs build #149532
nixos/*: split docs build #149532
Conversation
most of the modules that have gained an exemption from sandboxed doc builds either interpolate the version of the package they use into doc attributes, or they set |
nixos/modules/misc/documentation.nix
Outdated
specialArgs.pkgs = scrubDerivations "pkgs" pkgs; | ||
scrubbedEval = evalModules { | ||
modules = [ { | ||
nixpkgs.localSystem = config.nixpkgs.localSystem; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you should need this for docs.
Duplicating the evalModules
logic is not great for maintainability. Would it be feasible to use extendModules
when module filtering is supported by the module system itself?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you're right, that isn't needed here. wonder where that even came from now, probably from attempts to put nixpkgs.nix
into the sandbox (which failed anyway) 🤔
re evalModules
: we really have to duplicate this because both parts of the build must run with _module.check = false
, otherwise the build failed when were testing. not duplicating would be nice, but the savings of this PR come mostly from the docs build not reusing the eval we already have in any way. always open for suggestions though!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could do essentially extendModules { modules = [ { config._module.args.check = lib.mkForce false; } ]; }
for check
.
The only challenge is removing some modules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"some" is a bit of an understatement, there's over 1400 of them at time of writing 😄 filtering loaded modules like that would be possible if that facility existied, but evaluating a few user modules from scratch is probably faster. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finally making good on my 2-week-old promise...
I find it surprising that a bunch of mere strings are causing such an issue. Perhaps the feature could be less strict, though I wouldn't have noticed in practice if you removed it. |
it's not the strings that cause the issue, but how they are handled. the docs mechanism uses those strings as attrnames into |
Perhaps these could be replaced by links to |
turning them into links sounds like a good idea. the manpage build currently renders links in bold red, if we set the link text to something like |
Yeah, go for it :) |
in | ||
{ | ||
lazy = p.right; | ||
eager = p.wrong ++ optionals cfg.nixos.includeAllModules (extraModules ++ modules); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For includeAllModules
, you'd only have to add the user-provided modules, right? (in addition to p.wrong
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure. extraModules
was included in the docs build when we started, so we just kept it.
as far as we understand extraModules
(via NIXOS_EXTRA_MODULE_PATH) are always loaded but not included by default for performance reasons. it would be nice to include them in the cached part of the build, but like user modules they can reference arbitrary paths so that didn't work out :(
anything else we could do to make this any more awesome? :) (would merge it now if we could, two approvals seems good.) |
This (bisect says fc614c3) seems to have broken the installer tests, therefore blocking the nixos channels. The test fails with:
From what I remember the installer tests use |
So (partial?) revert for now to unblock channels? |
Unfortunately that still doesn't completely fix the regressions caused by this PR on
|
Usually these were addressed by extending |
d'oh. didn't let the installer test run through, so we didn't see those. will open a PR to disable the docs split for now until the installer issues are fully sorted. |
What I see is certainly just a test-only problem, so perhaps disable in the installer tests only? (unless a good |
What I see failing certainly are dependencies to generate docs (docbook, manual, manpages). |
we had tried disabling docs in the installer yesterday and had no success. could've been because tiredness, but at the moment i'd rather disable the split build to unblock the channel and have more time to analyse things. |
And I can't even revert it because it breaks the manual. |
@zowoq does it unbreak when reverting the kubernetes commits and setting |
seems so, the test does complete and the manual builds. #153951 |
This release fixes the issue (#50) where sandboxed documentation builds [1] fail when using the unstable Nixpkgs channel. [1] NixOS/nixpkgs#149532
This PR broke my NixOS configuration (with modules that customize existing modules) when switching from 21.11 to 22.05, and I had to bisect ( Here's a sample evaluation failure:
I'm currently trying to figure out how to make this build again without turning |
can you share a larger example that causes the errors you're seeing? could be that the doc split optimization simply isn't applicable in your case and turning it off could be the only option. |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/rebuilding-system-using-niv-fails-in-nixos-22-05/19667/7 |
Motivation for this change
almost all options documentation is constant, only very few options reference
pkgs
in attributes that end up in documentation. this fact can be used to build most of options doc in a derivation that can then be cached, and merging the rest of the docs (which can evaluated more cheaply now) separately.doing so reduces nixos-rebuild time quite significantly (by 20% or more), reducing build time on our system from 9.4 seconds to 7.4 seconds. disabling docs entirely reduces build time to 7.1 seconds, making the docs build as close to free as we can currently get.
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)nixos/doc/manual/md-to-db.sh
to update generated release notes