Skip to content
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

More robust documentation checks in CI #2661

Closed
jngrad opened this issue Apr 4, 2019 · 0 comments · Fixed by #2795
Closed

More robust documentation checks in CI #2661

jngrad opened this issue Apr 4, 2019 · 0 comments · Fixed by #2795

Comments

@jngrad
Copy link
Member

jngrad commented Apr 4, 2019

The Sphinx and Doxygen documentations keep piling up errors again. These issues are trivial to fix in the PRs where they emerge in the first place, whereas fixing them weeks after a merge involves a fair amount of guesswork (which can go wrong, as explained in the last meeting with the #2623 case) and has the potential to cause merge conflicts in other opened PRs. CI already fails when Sphinx warnings are raised, to some extent. We should make it more robust and do the same for Doxygen.

  • Sphinx: the -W option turns warnings into errors in the check_sphinx container, so issues are difficult to introduce. Unfortunately, some syntax errors are silently ignored by Sphinx. For example, a link to a non-existing Python function won't generate a warning:
    :meth:`espresso.electrostatics.P3M.Tune`
    There are currently several such examples in the documentation. Sometimes it's just a typo, sometimes the function moved and the paragraph must be updated accordingly. These errors can be spotted with a regex on the HTML output because Sphinx doesn't use line wrapping.
  • Doxygen: warnings aren't turned into errors, so the check_doxygen container can't fail. Some warnings are not caused by the code and can be filtered out with a regex. dot warnings can probably be removed with a command in the Doxyfile. Some errors are silently ignored, though:
    /** @brief Some function
     *  @return Number of neighbors.
     *  @param p  First particle
     *  @param dist
     *  Detailed explanation of the algorithm.
     */
     void foo(Particle &p, double dist);
    Here the second param has no description, which can be used as a trick to silence a warning about undocumented parameters, because Doxygen will automatically use the subsequent paragraph Detailed ... as the description for parameter dist. This behavior can be unpredictable: if paragraph Detailed... starts with any Doxygen command for paragraph-level markup, the second parameter description remains empty. This error can be spotted with a regex. The superfluous @return will raise a warning in a future release of Doxygen.
bors bot added a commit that referenced this issue May 7, 2019
2795: Add more documentation checks r=fweik a=jngrad

Closes #2661

Description of changes:
- broken links in Sphinx are now treated as errors
   + mostly incorrect namespaces, typos and incorrect names (e.g. `integer` instead of `int`)
- some Doxygen warnings are now treated as errors
   + warnings caused by known Doxygen bugs are ignored
   + warnings that don't change the html output are ignored
   + only unique warnings are displayed
- developers can use `maintainer/CI/doc_warnings.sh` and `maintainer/CI/dox_warnings.sh` to list Sphinx resp. Doxygen issues

Co-authored-by: Jean-Noel Grad <jgrad@icp.uni-stuttgart.de>
Co-authored-by: Jean-Noël Grad <jgrad@icp.uni-stuttgart.de>
@bors bors bot closed this as completed in #2795 May 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant