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

[Question/Discussion] Deadlinks checker in documents across the repo/library #345

Closed
neomatrix369 opened this issue Oct 17, 2020 · 10 comments · Fixed by #396
Closed

[Question/Discussion] Deadlinks checker in documents across the repo/library #345

neomatrix369 opened this issue Oct 17, 2020 · 10 comments · Fixed by #396
Assignees
Labels
enhancement New feature or request good first issue Good for newcomers ideas question Further information is requested

Comments

@neomatrix369
Copy link
Contributor

Just like I have this issue on neomatrix369/awesome-ai-ml-dl#54, I have found a way to manually check for deadlinks in all of my markdown files in a repo.

I think there should be something that looks for such links in .rst and other document files as well.

When we find out, it would be good to add it to the pre-commit CI/CD GH action.

Can also be added to the local pre-commit.

In both cases it should be run when files that may contain hyperlinks are being committed

@neomatrix369 neomatrix369 added enhancement New feature or request question Further information is requested labels Oct 17, 2020
@neomatrix369 neomatrix369 added the good first issue Good for newcomers label Oct 17, 2020
@s-weigand
Copy link
Contributor

s-weigand commented Oct 17, 2020

Why not just use python -m sphinx . _build -b linkcheck/make linkcheck inside the docs dir?
I have the following in my workflows.

@MarcoGorelli
Copy link
Collaborator

Great idea!

When we find out, it would be good to add it to the pre-commit CI/CD GH action.

Can also be added to the local pre-commit.

Anything that runs as a local pre-commit hook also runs in the GH pre-commit action.

Why not just use python -m sphinx . _build -b linkcheck/make linkcheck inside the docs dir

Nice! I think that would make for a great local pre-commit hook (so that feedback is faster than if you wait for the CI jobs)

@s-weigand
Copy link
Contributor

IMHO having it as tox tests (e.g. tox -e docs and tox -e links) would make more sense, since the docs aren't changed that often and the tests take quite some time. I don't think anyone would want to wait 20sec per commit.

@MarcoGorelli
Copy link
Collaborator

I didn't realise it took that long - sure, that makes sense then!

@neomatrix369
Copy link
Contributor Author

Looks like you guys have actioned this suggestion already - super cool!

@MarcoGorelli
Copy link
Collaborator

Looks like you guys have actioned this suggestion already

Are you sure? I didn't think we had 🤣

@neomatrix369
Copy link
Contributor Author

Looks like you guys have actioned this suggestion already

Are you sure? I didn't think we had 🤣

Oh! Really! You haven't :P ! Few ideas were thrown, in the conversations above - not worth pursuing? I was suggesting for the .md files and not just the docs generated.

But maybe it's not useful or applicable.

@MarcoGorelli
Copy link
Collaborator

Yes, I think it's useful (thanks for the suggestion!), we just haven't got round to doing it yet

@neomatrix369
Copy link
Contributor Author

Yes, I think it's useful (thanks for the suggestion!), we just haven't got round to doing it yet

I'll give it a whirl, leave it to me, and if don;t then just beat me to it! ;)

@neomatrix369 neomatrix369 self-assigned this Oct 21, 2020
@s-weigand
Copy link
Contributor

@neomatrix369 the link check should be allowed to fail on CI, since servers might be temporarily down (e.g. codecov times out quite often).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers ideas question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants