| # Docgen using Sphinx with Bazel | |
| The `sphinxdocs` project allows using Bazel to run Sphinx to generate | |
| documentation. It comes with: | |
| * Rules for running Sphinx | |
| * Rules for generating documentation for Starlark code. | |
| * A Sphinx plugin for documenting Starlark and Bazel objects. | |
| * Rules for readthedocs build integration. | |
| While it is primarily oriented towards docgen for Starlark code, the core of it | |
| is agnostic as to what is being documented. | |
| ## Optimization | |
| Normally, Sphinx keeps various cache files to improve incremental building. | |
| Unfortunately, programs performing their own caching don't interact well | |
| with Bazel's model of precisely declaring and strictly enforcing what are | |
| inputs, what are outputs, and what files are available when running a program. | |
| The net effect is programs don't have a prior invocation's cache files | |
| available. | |
| There are two mechanisms available to make some cache available to Sphinx under | |
| Bazel: | |
| * Disable sandboxing, which allows some files from prior invocations to be | |
| visible to subsequent invocations. This can be done multiple ways: | |
| * Set `tags = ["no-sandbox"]` on the `sphinx_docs` target | |
| * `--modify_execution_info=SphinxBuildDocs=+no-sandbox` (Bazel flag) | |
| * `--strategy=SphinxBuildDocs=local` (Bazel flag) | |
| * Use persistent workers (enabled by default) by setting | |
| `allow_persistent_workers=True` on the `sphinx_docs` target. Note that other | |
| Bazel flags can disable using workers even if an action supports it. Setting | |
| `--strategy=SphinxBuildDocs=dynamic,worker,local,sandbox` should tell Bazel | |
| to use workers if possible, otherwise fallback to non-worker invocations. | |
| ```{toctree} | |
| :hidden: | |
| starlark-docgen | |
| sphinx-bzl | |
| readthedocs | |
| ``` |