Skip to content

Commit 3768c00

Browse files
committed
feat: more insights from experimenting
1 parent 5cd1ef9 commit 3768c00

1 file changed

Lines changed: 15 additions & 9 deletions

File tree

docs/design_decisions/DR-008-infra.rst

Lines changed: 15 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -108,7 +108,9 @@ Option B: Introduce ``:docs_src_dir`` Bazel target
108108
We add an ``extra_docs`` attribute to the ``docs()`` macro
109109
for additional sources specified via `sphinx_docs_library <https://rules-python.readthedocs.io/en/1.0.0/api/sphinxdocs/sphinxdocs/sphinx_docs_library.html#sphinx_docs_library>`_,
110110
which allows to adapt path prefixes.
111-
The we materialize a composed folder for the actual sphinx-build.
111+
The source tree is materialized using hardlinks (``ln``) inside a Bazel ``declare_directory`` action.
112+
Symlinks fail Bazel's output tree validation (dangling link detection),
113+
while copies are unnecessarily expensive for large doc sets.
112114

113115
.. mermaid::
114116

@@ -128,22 +130,26 @@ Thus, there is no ``:live_preview`` target but a ``live_preview`` script.
128130
We cannot rely on watching file system changes to trigger rebuilds because the source directory is composed by Bazel
129131
and may contain generated files.
130132

131-
For the implementation we can rely on `ibazel / bazel-watcher <https://github.com/bazelbuild/bazel-watcher>`_
132-
to trigger rebuilds of the ``:docs_src_dir`` target and then still use sphinx-autobuild for the browser auto-reload.
133-
As a side-effect, ibazel is a new tool in S-CORE which could be reused for other auto-rebuild use cases like unit tests.
133+
The ``live_preview`` script runs two concurrent processes:
134+
135+
1. ``ibazel build :docs_src_dir`` — watches workspace sources and re-materializes the tree on change.
136+
2. ``sphinx-autobuild`` — watches the materialized tree and serves HTML with websocket-based browser reload.
134137

135138
The ``score_sync_toml`` extension writes a ``ubproject.toml`` file to the source directory
136139
but Bazel sandboxing makes this fail.
137-
As a workaround, ``needscfg_outpath`` can be used to redirect it somewhere else.
138-
Alternatively, ``remove score_sync_toml`` and ``needs_config_writer`` extensions and create the ubproject.toml file in a different way?
140+
The ``score_sync_toml`` extension's write to the source directory is redirected via
141+
``--define=needscfg_outpath=<workspace>/docs/ubproject.toml``,
142+
which works without modifications to the extension itself.
139143

140144
Effort 😡: Some implementation effort.
141145

142146
Flexibility 💚: Generic solution for all build paths and future extensions.
143147

144-
Speed ?: unclear
148+
Speed 💛: Overall latency is comparable to the status quo for edit-preview cycles, but the initial cold start is a little slower due to the extra Bazel invocation.
145149

146-
UX 😡: Live-preview requires a setup step to generate the script.
150+
UX 😡: Requires a two-step setup: ``bazel run //:ide_support`` (venv) then
151+
``bazel run //:gen_live_preview`` (script).
152+
The generated script is workspace-specific and should be gitignored.
147153

148154

149155
Option D: Dual-path — keep ``:live_preview``, add hermetic ``:docs`` build
@@ -173,7 +179,7 @@ In order of importance, most important first.
173179

174180
Flexibility, 😡, 💚, 😡
175181
Effort, 💚, 😡, 😡
176-
Speed, 💚, ?, 💚
182+
Speed, 💚, 💛, 💚
177183
UX, 💚, 😡, 😡
178184

179185
**Decision: Option B** because Option N loses wrt flexibility. Option D has no advantage over B.

0 commit comments

Comments
 (0)