-
Notifications
You must be signed in to change notification settings - Fork 72
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
🧪 CI: Fail on sphinx-build warnings #974
The head ref may contain hidden characters: "\u{1F9EA}-CI-Fail-on-doc-build-warnings"
Conversation
Thanks for the PR, I'm waiting for a merge till we fixed all the stuff first, otherwise it will block our CI. And somehow yes, #973 got created, because I had problems identifying the root cause of PlantUML errors, as the exact location was not printed. And because other user have also asked for it, I created a not-so-clean, but doable fix. |
For PlantUML errors, notice also #977, which describes problems in |
Oh indeed, thats why it marked as a draft 😄 |
From #982, these are the actual origin of the remaining warnings:
|
There should be no reason why a non-headless JVM is ever required and, without it, sphinx builds are slower and constantly switch window focus
In plantuml V1.2022.12 (23 Oct, 2022), it became a syntax error not to use `@startgantt`: https://plantuml.com/changes fixes #977
This commit adds source origin information to plantuml nodes, so that they can be reported by Sphinx warnings (for example if the render fails). Note, that this change also requires sphinx-contrib/plantuml#79, to actually emit the source positions during sphinx builds
This makes it easier to run the test suite, since it inhibits window focus switching
These are unnecessary for the running of the tests, and this makes them more minimal
To add links in the API documentation and remove build warnings
Needs functions were being parsed the sphinx env, as opposed to the required sphinx app, as the first argument.
Only report file names
Accessing sphinx-needs configuration via the sphinx `Config` object is difficult to work with and ensure type safety, due to its dynamic nature. This commit moves all configuration specification to the `NeedsSphinxConfig` class, which is a thin wrapper around the sphinx `Config`, to define and provide type safe access to the sphinx-need specific configuration. This is non-breaking change, since all configuration can still be accessed via the sphinx `Config`, (although this is now discouraged).
The sphinx-needs data stored on the Sphinx `BuildEnvironment` is currently difficult to interpret and work with, since the dynamic nature of `BuildEnvironment` provides no type safety or static introspection. This commit centralises access to sphinx-needs data, via `sphinx_needs.data.SphinxNeedsData`, which is a thin wrapper around the sphinx `BuildEnvironment`, to define and provide type safe access to the sphinx-need specific data. `TypedDict` are used to type annotate the dictionary keys for the different data types, and thus `sphinx_needs.data` essentially provides a schema for the data that sphinx-needs stores. This is a non-breaking change, since all data can still be accessed via the sphinx `BuildEnvironment`, (although this is now discouraged).
This commit makes `NEEDS_CONFIG` specific to the actual data that it holds, rather than just a generic data store.
This makes it easier to run pre-commit in isolation, with no system dependencies other than pre-commit itself.
This PR adds strict typing to most of the package, building on #987 and #998 to try to confine use of dynamic types to a small surface area. This hopefully makes it easier for developers to navigate the code base, and lessens the potential for bugs arising from type mismatches. --- There are still some open questions, particularly around `NeedsInfoType`, which 1. has some dynamic fields (such as user defined links/options) and, 2. has some fields which are only set after post-transforms (such `process_need_nodes`)
Bumps cypress-io/github-action from 5 to 6.
Previously, hidden needs would not be added to the doctree. However, this meant that the `add_sections` transform did not add section related fields to the needs data. This caused errors in the docs builds when filters required these fields. The needs node is now created in the doctree, but marked with a `hidden` attribute, and these nodes are removed before rendering.
superceded by #1005 |
Thanks for #972 @danwos, now I can actually build the docs 😅
However, I noticed that there were still lots of warnings occuring, e.g. plantuml errors (is this what #973 is intending to fix?)
This change to the CI, should make these warnings fail the job (then obviously we need to fix those warnings)
See also #975