You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We current offer two ways to build the docs:
1. Build an arbitrary book with `--doc` and its companion arguments like
`--resource` and `--asciidoctor`.
2. Build *all* of the books that Elastic publishes with `--all`.
Building an arbitrary book is nice and quick because it is have very
little overhead on top of the time it takes to build the actual book.
But it isn't always the best test because the command that you use to
build the book might not exactly match the invocation that `--all` uses
to build the book. Furthermore, building a single book is not usually
enough! When you are testing documentation changes that you've made
locally you often don't know all of the books that your changes might
effect. The Elasticsearch repository is used in about a dozen books in
combination with a hand full of other repositories.
Building all of the docs is quite slow and you might run into errors
that you didn't cause. It is exactly what we need to build the docs for
the public web site but it isn't right for testing some changes that you
make locally. It also doesn't line up properly with local development as
it only knows how to pull repos from the Elastic organization at github.
This change adds a "third way" to build test the docs that splits the
difference between the two options. It uses the same mechanisms that we
usually use to build all of the docs but allows you to substitute local
directories in place of some branch of some repo:
```
./build_docs --all --target_repo [email protected]:elastic/built-docs.git \
--keep_hash \
--sub_dir elasticsearch:master:~/Code/elasticsearch
```
This is nice because it:
1. Rebuilds all of the books that your local directory is involved with
2. Uses standard switches when building each of those books
3. Does not rebuild books that don't use your local directory
That third thing is actually caused by that new `--keep_hash` flag. It
causes the build's up-to-date checking to use the same hash that was
used the last time the book was built. `--keep_hash` has uses beyond
being paired with `--sub_dir`. In particular, it is useful when testing
what happens when you switch a book to Asciidoctor. You can switch the
book to Asciidoctor in `conf.yaml` and rebuild with `--keep_hash` and
the build will *only* have the asciidoctor change in it.
This also drop `--no_fetch` because `--keep_hash` is better in almost
every way.
The goal of `--sub_dir` isn't so much that people will execute it
locally, but that we can execute it on CI. I'm sure folks will execute
it locally but it pretty heavy because, just like a normal `--all` build
it has to:
1. Clone the `built-docs` repo or fetch updates if it is already cloned.
2. Check out the `built-docs` repo. This is truly slow because it has
many, many files in it.
3. Clone all of the repos used to build every book or fetch updates if
they are already cloned.
I suspect in time we can fix some of these. But for now, this is a heavy
thing.
0 commit comments