issues: 502130982
This data as json
| id | node_id | number | title | user | state | locked | assignee | milestone | comments | created_at | updated_at | closed_at | author_association | active_lock_reason | draft | pull_request | body | reactions | performed_via_github_app | state_reason | repo | type |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 502130982 | MDU6SXNzdWU1MDIxMzA5ODI= | 3370 | Hundreds of Sphinx errors | 6213168 | closed | 0 | 14 | 2019-10-03T15:17:09Z | 2022-04-17T20:33:05Z | 2022-04-17T20:33:05Z | MEMBER | sphinx-build emits a ton of errors that need to be polished out: https://readthedocs.org/projects/xray/builds/ -> latest -> open last step Options for the long term: - Change the "Docs" azure pipelines job to crash if there are new failures. From past experience though, this should come together with a sensible way to whitelist errors that can't be fixed. This will severely slow down development as PRs will systematically fail on such a check. - Add a task in the release process where, immediately before closing a release, the maintainer needs to manually go through the sphinx-build log and fix any new issues. This would be a major extra piece of work for the maintainer. I am honestly not excited by either of the above. Alternative suggestions are welcome. |
{
"url": "https://api.github.com/repos/pydata/xarray/issues/3370/reactions",
"total_count": 0,
"+1": 0,
"-1": 0,
"laugh": 0,
"hooray": 0,
"confused": 0,
"heart": 0,
"rocket": 0,
"eyes": 0
} |
completed | 13221727 | issue |