-
Notifications
You must be signed in to change notification settings - Fork 204
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
Update bad links #2080
Update bad links #2080
Conversation
# Development Model | ||
|
||
CUB follows the same development model as Thrust, described | ||
[here](https://nvidia.github.io/thrust/releases/versioning.html). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was not able to find a corresponding section in the currently deployed docs.
@@ -255,8 +255,7 @@ Other Enhancements | |||
|
|||
- NVIDIA/thrust#1512: Use CUB to implement ``adjacent_difference``. | |||
- NVIDIA/thrust#1555: Use CUB to implement ``scan_by_key``. | |||
- NVIDIA/thrust#1611: Add new doxybook-based Thrust documentation at | |||
https://nvidia.github.io/thrust. | |||
- NVIDIA/thrust#1611: Add new doxybook-based Thrust documentation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unclear that the current new-new docs are still the old-new doxybook docs, just linking only to the PR seemed safest
For reference
|
/ok to test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the fixes!
🟨 CI finished in 8h 05m: Pass: 94%/250 | Total: 2d 00h | Avg: 11m 32s | Max: 1h 09m | Hits: 92%/238455
|
Project | |
---|---|
CCCL Infrastructure | |
libcu++ | |
+/- | CUB |
+/- | Thrust |
CUDA Experimental | |
pycuda |
Modifications in project or dependencies?
Project | |
---|---|
CCCL Infrastructure | |
libcu++ | |
+/- | CUB |
+/- | Thrust |
CUDA Experimental | |
+/- | pycuda |
🏃 Runner counts (total jobs: 250)
# | Runner |
---|---|
178 | linux-amd64-cpu16 |
41 | linux-amd64-gpu-v100-latest-1 |
16 | linux-arm64-cpu16 |
15 | windows-amd64-cpu16 |
OK last commit 76b4bd2 gets things to zere errors with
I'd suggest adding something like that to the CI docs job in a follow-on PR. A few notes:
Not sure why |
/ok to test |
🟨 CI finished in 2h 30m: Pass: 99%/250 | Total: 1d 19h | Avg: 10m 21s | Max: 1h 03m | Hits: 95%/248302
|
Project | |
---|---|
CCCL Infrastructure | |
libcu++ | |
+/- | CUB |
+/- | Thrust |
CUDA Experimental | |
pycuda |
Modifications in project or dependencies?
Project | |
---|---|
CCCL Infrastructure | |
libcu++ | |
+/- | CUB |
+/- | Thrust |
CUDA Experimental | |
+/- | pycuda |
🏃 Runner counts (total jobs: 250)
# | Runner |
---|---|
178 | linux-amd64-cpu16 |
41 | linux-amd64-gpu-v100-latest-1 |
16 | linux-arm64-cpu16 |
15 | windows-amd64-cpu16 |
🟩 CI finished in 7h 52m: Pass: 100%/250 | Total: 1d 19h | Avg: 10m 33s | Max: 1h 03m | Hits: 95%/250036
|
Project | |
---|---|
CCCL Infrastructure | |
libcu++ | |
+/- | CUB |
+/- | Thrust |
CUDA Experimental | |
pycuda |
Modifications in project or dependencies?
Project | |
---|---|
CCCL Infrastructure | |
libcu++ | |
+/- | CUB |
+/- | Thrust |
CUDA Experimental | |
+/- | pycuda |
🏃 Runner counts (total jobs: 250)
# | Runner |
---|---|
178 | linux-amd64-cpu16 |
41 | linux-amd64-gpu-v100-latest-1 |
16 | linux-arm64-cpu16 |
15 | windows-amd64-cpu16 |
* fix broken links * revert repo.toml * linkchecker fixes * fix .cuh errors * lint
* fix broken links * revert repo.toml * linkchecker fixes * fix .cuh errors * lint
This PR updates bad links found Sphinx's built-in
linkcheck
utiltity, without implementing any automatic link checks in CI. There are other tools that may be worth considering, that may be faster and find more links. A few question comments are left inline.For reference, here is a diff for
repo.toml
that addslinkcheck
to the build.Using
linkcheck
has some disadvantages. It seems to duplicate all the build stages, not including the actual link checking, which also takes non-trivial time, more than doubling the overall docs build time. It is also currently hard to configure fromrepo.toml
and will always fail the build as far as I can tell, risking PRs to fail for unrelated reasons if/when external sites change independently. This could probably be mitigated by defining a second "repo.toml" that is responsible for the link checking that could be run on a different schedule.Another option would be to use a separate tool to scan the built HTML. One popular too seems to be linkchecker. It seems to find a few more issues that
linkcheck
missed. It could be run in a separate task in the GH job after the existing docs build. This could either hard fail on new bad links, or be run in an advisory capacity (just generate a report) One disadvantage is that the results do not point directly back to source ReST files, but it's still usually straightforward to find the correct place to fix.All things together, I think I would advise using
linkchecker
over Sphinxlinkcheck
. (It is pip or apt installable, I am not sure where the package list for the dev containers is configured.)