Repository navigation
Preserve source development loaders during documentation builds - #1171
Conversation
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Preserve the source loader in documentation mode PowerForge.PowerShell/Services/ModulePipelineRunner.MergeAndTests.cs, Docs/PSPublishModule.DevelopmentBootstrapper.md, Docs/PSPublishModule.ModuleDocumentation.md |
The pipeline skips source development bootstrapper handling in Documentation mode. The documentation states that this mode preserves the source .psm1 loader. |
Test loader preservation across development-binary modes PowerForge.Tests/ModulePipelineScriptExecutionSeamTests.DocumentationBootstrapper.cs, .github/workflows/BuildModule.yml |
A test theory checks byte-for-byte loader preservation for three development-binary modes. The Linux build workflow runs the related test groups. |
Priority:
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Bug fix
Merge Risk: 
Minimal · up to d2874
-
Documentation builds preserve the source loader, with regression coverage for the supported development-binary modes. No merge-blocking issue is identified.
Pre-merge checks: 
4 · 
1
-
Failed checks: 1 warning Passed checks: 4 passed-
Full details: Title check
-
Explanation
The title states the main change: documentation builds now leave source development loaders (the source .psm1 bootstrapper) unchanged. The raw summary confirms this: TryRegenerateSourceDevelopmentBootstrapperFromManifest returns early for Documentation gate mode, the docs describe byte-for-byte preservation, and a regression test covers Auto, Environment, and Off modes. The CI workflow change and docs updates support the same change. No unrelated or misleading content was found.
-
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 2 files. (3 skipped: 3 unsupported.)
Resolution
Write docstrings for the functions missing them to satisfy the coverage threshold.
-
Finishing Touches: 💡 1
-
📝 Generate docstrings: 💡
-
- Commit to this branch
- Create a new PR
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
I reproduced ConsoleMonster's documentation build removing exactly the five-line
System.Management.Automationhost-assembly guard from its generated development loader when using PSPublishModule 3.0.168. Currentmainalready includes that guard, but documentation mode still regenerates the source bootstrapper through the normal build path; an older generator can therefore overwrite a newer committed loader.This skips source development-loader regeneration in documentation mode. Staging still gets the loader needed for documentation, and the source manifest's exports can still refresh. Normal builds continue to regenerate or clear development loaders. The source
.psm1stays byte-for-byte unchanged, including when development binaries areOfffor the docs run.Auto,Environment, andOff, covering retained loader content, encoding and line endings. All three fail before the fix.Auto,ReplaceSingleFile, and assembly-load-context loading.Validation:
net8.0andnet10.0succeeded.ab25431fe4f79fc487643f8c0e1765da056f72f8, I ranModule/Build/Build-Module.ps1 -RunMode Documentation -SignModule:$false -SkipInstall:$truewith the source-built fixed module. The build passed with 137 Markdown command pages matching 137 MAML entries. The committed and regenerated.psm1SHA-256 hashes match exactly.EphemeralKeySet, case-sensitive filesystem assumptions, and a backslash lifecycle-action working directory. I stopped that selection after repeated platform failures; it is not a passing full-suite result. A broader portable selection finished with 821 passed, 3 skipped and one binary-documentation snapshot line-ending failure. I reproduced that failure, the lifecycle-action path failure and the case-sensitive destination test failure against the original pipeline as well.For ConsoleMonster, updating
Website/.powerforge/engine-lock.jsonalone does not update the module builder.Module/Build/Build-Module.ps1imports PSPublishModule by name, so the documentation process needs a PSPublishModule release containing this fix (or an explicit local source build for qualification). The website lock currently selectsa59da372d66af663a6591a9e7d4d9aa3abc4547c; its engine update is a separate consumer step. This PR does not publish a package.Summary by CodeRabbit