[V2:15] Add Targeted Build Rendering#29
Open
ritorhymes wants to merge 12 commits into
Open
Conversation
This was referenced May 5, 2026
fabd49c to
0c231fb
Compare
0c231fb to
fce78c0
Compare
This was referenced Jun 19, 2026
Add workspace-local `.build-eips.toml` loading and starter configuration. Introduce `config::ActiveRepo` to load the selected checkout’s `Build.toml`, validate explicit `-C` roots, and expose active repository context to later commands. Keep source materialization, initialization, and diagnostics in their owning later branches.
Add clean and dirty source materialization for the active repository and sibling content. Use `config::RepositoryUse` throughout the runtime path, preserve tracked working-tree materialization and `index_path`, and reject dirty active manifests in clean modes. Build, check, and serve prepare sources without fetching the active upstream; `changed` retains upstream fetching for comparison.
Add workspace initialization from the selected active `Build.toml`. Clone missing sibling repositories from declared locations and initialize a missing theme checkout from the manifest repository and pin. Preserve existing usable checkouts and fail without deleting unusable paths. Write `.build-eips.toml` only when absent and generate `WORKSPACE.md` for the initialized workspace.
Add `build-eips doctor` for validating workspace configuration, active `Build.toml`, managed sibling repositories, the local theme checkout, and required tools. Report ok/warn/fail diagnostics; invalid active manifests and unusable theme configuration fail, while expected sibling and theme-pin conditions can warn. Keep diagnostics read-only and leave execution and runtime behavior to later branches.
Resolve build, check, and serve source policy around local active sources, clean mode, remote siblings, build roots, and base URL precedence. Keep `--clean` and `--remote-siblings` as source controls and limit `--only` to supported local dirty modes. Route runtime commands through one resolved execution policy.
Run Zola with the editable `workspace/theme` checkout. Materialize tracked local theme files into prepared `themes/eips-theme`, load Zola and eipw configuration from that local checkout, and keep runtime commands independent of manifest network access.
Add prepared runtime build pipeline. Materialize active and sibling sources according to resolved execution policy, preprocess merged proposal content, prepare the local theme mount, and invoke runtime checks and rendering from `pipeline.rs`. Keep serve watch and sync behavior in the serve runtime branch.
Add server binding resolution and serve-only host/port flags for local Zola serve commands. Run Zola serve with the resolved server binding, optional base URL override, fast/force serve flags, and generated output directory. Add dirty serve watching for dirty active-repo paths and local theme changes. Clean mode disables active-repo sync but keeps theme sync.
Add build-eips preview for serving the existing resolved output directory without rebuilding or starting dirty sync. Reuse server binding resolution and preview-only host/port flags, and report missing output before binding the local server. Add a tiny_http static file server with safe path resolution, index-file fallback, basic content types, and preview path tests.
Add proposal number parsing, proposal path classification, and content-path helpers for flat and directory proposal layouts. Introduce the proposal-selection data needed by later editorial and targeted-rendering commands while leaving user-facing render selection, render-plan construction, and targeted rendering behavior to their owning later branches.
Add `build-eips editorial lint` and `build-eips editorial check` as the first user-facing proposal-selection commands. Keep eipw options scoped to editorial lint/check. Normal build, check, and serve prepare runtime sources, preprocess markdown, and run Zola without carrying eipw source-selection flags. Run editorial-selected eipw lint against the prepared merged source tree so cross-repo EIP/ERC references resolve through the same content layout used by local builds. Prepare runtime sources from the local active checkout, merge sibling repositories, and keep active-upstream fetches in changed-file comparison and editorial `--against-upstream` target selection.
Add targeted build rendering. Resolve `--only` and `[render].only` for local dirty builds, create an `OnlyRenderPlan`, rewrite links for omitted proposal content, and prune unselected content before Zola. Keep targeted mode restrictions enforced by execution policy.
fce78c0 to
0076121
Compare
This file contains hidden or 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
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.
Summary
This PR adds the first user-facing targeted rendering slice for V2: build-only proposal selection through
build --only <NUMBER>...and workspace[render].onlydefaults. Selection resolves intoResolvedExecution::onlywith CLI values overriding config and applies only to local dirty builds (CLI--onlyis rejected on other forms;[render].onlyis silently ignored outside that scope); it builds anOnlyRenderPlanafter source and sibling materialization, keeps references between selected proposals internal, rewrites links andrequiresentries for omitted proposals to public EIP/ERC URLs, and prunes unselected proposal content before Zola runs. It does not add targeted serve behavior, so review should focus on selection applicability, CLI-versus-config precedence, selected-versus-omitted reference handling, and pruning.--only <NUMBER>...CLI selection for targeted local rendering.[render].onlydefaults to.build-eips.tomland the starter config.ResolvedExecution::only, with CLI values overriding workspace config values.--onlyis rejected outside applicable build forms, and config[render].onlyis ignored outside applicable local dirty builds.OnlyRenderPlanduring prepared runtime setup and pass it into markdown preprocessing.requiresentries that point at omitted proposals to public EIP/ERC URLs.requiresreferences between selected proposals.Review Notes
This PR is the first user-facing targeted rendering slice. It consumes the proposal-selection foundation from V2:13 and applies it to
buildonly. Targeted serve behavior is intentionally deferred to V2:16, where dirty serve sync and incremental preprocessing need additional filtering rules.--onlyis accepted only onbuild. Execution policy applies it only to default local dirty builds and rejects it with--cleanor--remote-siblings;serveandcheckdo not accept it. Workspace[render].onlyis ignored unless execution resolves to a local dirty build.Workspace
[render].onlyis a default for applicable local dirty builds. Command-line--onlyoverrides the config value. Missing[render], missingonly, andonly = []all mean full rendering.OnlyRenderPlanis built after active and sibling sources are materialized and merged into the prepared repo. That lets targeted selection operate on the actual content tree Zola will render, including sibling proposal content.Markdown preprocessing uses the plan to keep selected proposal references internal and rewrite references to omitted proposals as public URLs. This applies to normal markdown links and proposal
requiresfront-matter entries. Query strings and fragments on rewritten markdown links are preserved.After preprocessing, unselected proposal files and proposal directories are pruned from
content/. Non-proposal content such as_index.mdremains available so the selected output still has the surrounding site structure.Verification
src/cli.rsforOnlyCliArgs, build-only--onlyparsing, invalid selector rejection, and rejection on serve/check forms.src/config.rsfor[render].only, starter config serialization, config parsing, empty/missing render behavior, and invalid render-only values.src/execution.rsfor targeted selection resolution, CLI-over-config precedence, deduplication, local dirty build applicability, and rejection of unsupported--onlymodes.src/pipeline.rsforOnlyRenderPlanconstruction after source materialization/merge, markdown preprocessing with the plan, and pruning before Zola runs.src/markdown.rsfor targeted markdown filtering, external URL rewriting,requiresrewriting, pruning-safe preprocessing, query/fragment preservation, and tests.src/editorial.rsonly for theResolvedExecution::onlytest fixture update; editorial behavior is otherwise unchanged here.src/serve.rsonly for the non-targetedmarkdown::preprocess(..., None)call; targeted serve is deferred to V2:16.