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

tox -e docs: linkcheck very flaky #806

Closed
obestwalter opened this issue May 1, 2018 · 2 comments
Closed

tox -e docs: linkcheck very flaky #806

obestwalter opened this issue May 1, 2018 · 2 comments
Assignees
Labels
help:wanted Issues that have been acknowledged, a solution determined and a PR might likely be accepted. type:internal should have no impact on the user (refactoring, infrastructure, tools, etc.)
Milestone

Comments

@obestwalter
Copy link
Member

obestwalter commented May 1, 2018

This check is definitely useful and should be done regularly, but sadly is very flaky.

This is what I can think of:

  • remove it from normal builds and make this check a part of the release, still having a regular check for dead links but having less flaky builds.
  • wrap this step to be a proper test and introducing pytest-rerunfailures to the mix.
  • run these checks every time but not fail, if dead links are detected (my least favorite appproach, because those tests tend to be ignored then)
@obestwalter obestwalter added the type:internal should have no impact on the user (refactoring, infrastructure, tools, etc.) label May 1, 2018
@obestwalter obestwalter self-assigned this May 1, 2018
@gaborbernat
Copy link
Member

what about 3 and 1 together 😄

@gaborbernat gaborbernat added this to the 3.5 milestone Sep 18, 2018
@gaborbernat gaborbernat modified the milestones: 3.5, 3.6 Oct 8, 2018
@gaborbernat gaborbernat modified the milestones: 3.6, 3.7 Dec 16, 2018
@gaborbernat gaborbernat added the help:wanted Issues that have been acknowledged, a solution determined and a PR might likely be accepted. label May 3, 2019
@gaborbernat gaborbernat modified the milestones: 3.7, 4.0 Jan 13, 2022
@gaborbernat
Copy link
Member

With the implementation of sphinx-doc/sphinx#7388 I think this should be less of an issue, so I'll enable the check unconditionally on the rewrite branch and see where it goes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help:wanted Issues that have been acknowledged, a solution determined and a PR might likely be accepted. type:internal should have no impact on the user (refactoring, infrastructure, tools, etc.)
Projects
None yet
Development

No branches or pull requests

2 participants