-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove some MkDocs log noise #1815
Conversation
4897ff5
to
ba74727
Compare
Deploying with Cloudflare Pages
|
Checked the links by hand in the ehrQL preview, and a preview of the OpenSAFELY documentation site that incorporates this ehrQL branch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good AFAICT
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
(Yes, that doesn't sound like a contradiction at all.) Files in the top-level `/includes/` directory are actually included by the snippet support in pymdown-extensions, instead of directly included. This exclusion is to: * prevent the `includes/` directory from being included as built HTML pages themselves (which is in addition to their use as snippets in other built HTML pages) * allows suppressing of MkDocs warnings from these pages for `mkdocs build` and `mkdocs serve --clean`. (These warnings are because the relative links in the `includes/` source don't point to their intended actual links in the source directory, but they do when included as snippets.) The preceding `/` in `/includes/` is to exclude only the top-level `/includes/` directory to keep the exclusion rule specific; the option uses a `.gitignore` pattern format. See https://www.mkdocs.org/user-guide/configuration/#exclude_docs
This suppresses more MkDocs log noise. These pages are intended to be included, but are currently listed on a index-style page that gives more context.
Some of the existing links work in the ehrQL docs build, but not the main OpenSAFELY documentation site. This is because: * some of the existing links are either absolute links to the URL root, or relative paths that go the URL root, before descending * the ehrQL docs build preview has all the content at the URL root, and not, like the OpenSAFELY documentation site, in `/ehrql/`, so there's a mismatch of the depth of URLs there It would be good to make the two sites consistent: that is, make the ehrQL preview actually have URLs like: `/ehrql/how-to/…` instead of `/how-to/…` — it would remove the possibility for this kind of broken link.
This does not change the rendering, but does remove the MkDocs warnings. It uses a `.md` suffix, so MkDocs can find the file, and adjusts the relative path.
* Use code formatting * Remove rogue trailing quote
This link is broken in two ways: * it's an absolute link, which doesn't work in the OpenSAFELY documentation (but does in the ehrQL preview) * it always links to the `core` schema, whereas the intent is probably to keep the link to the same schema — this appears for `tpp`, for example
ba74727
to
19ca009
Compare
I've left the |
The MkDocs logs when serving or building the documentation are noisy, and are at least a screenful of information for me on my display configuration.
This hides information that might actually be useful to people when working on the documentation: new problems that might have been introduced when editing aren't obvious.
This PR reduces, but does not entirely remove, the noise by:
Other notes
just docs-serve --clean
— this takes account of theexclude_docs
option I've configured inmkdocs.yml
. This excludes theincludes/
directory, which is a source of multiple false positives. Perhaps we should make--clean
the default injust docs-serve
? (Sometimes people might want to preview excluded documents, such as adrafts/
directory, which is why this is not the default MkDocs behaviour.)/how-to/…
, while the OpenSAFELY site has paths like/ehrql/how-to/…
. Because of this, some links — either from absolute paths or from relative paths that reach the URL root — work in the ehrQL preview, but are broken on the OpenSAFELY site. I'm not sure why the OpenSAFELY link check doesn't catch these. I opened an issue for restructuring the ehrQL preview.includes/
as accessible pages. Because we still have the quirk of having to duplicate our configuration, we should configure it there too.ehrql/docs
. This might be a little bit trickier to get right, so I've opened an issue to document the problem, and it can be a separate PR.