Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Automatically submit as issues detected broken links #7

Open
dontcallmedom opened this issue Dec 4, 2020 · 6 comments
Open

Automatically submit as issues detected broken links #7

dontcallmedom opened this issue Dec 4, 2020 · 6 comments
Assignees

Comments

@dontcallmedom
Copy link
Member

w3c/reffy#455 allows to identify clearly broken links - these should be submitted as github issues on the relevant repo.

(we discussed whether to try to run this as a regular automatic issue report, but figuring out when a link was previously reported as broken may not be simple - we should at least start by a one-off, and it may be sufficient to run that one-off rarely enough that we can assume the previously raised issue would have been closed)

@dontcallmedom
Copy link
Member Author

this was mostly done in #77 - needs to enable this to happen on a regular basis to close

@tabatkins
Copy link
Member

In w3c/csswg-drafts#8118 we got an incorrect notification from the bot - the linked spec is live-compiled by ReSpec, so the target anchor does exist after compilation is finished.

Strudy should either be able to check the post-compiling version of such specs, or just detect that they're live-compiled and assume that all links into such documents will exist at some point. (Better to have this be wrong and leave a broken link in a spec, than have working links incorrectly flagged as broken with no way to fix the notification.)

@dontcallmedom
Copy link
Member Author

sorry about the false positive - the tool definitely works on top of the ReSpec post-compiled content (so shouldn't have flagged this as an error), and on top of that, we manually review reports before they get submitted.

I'll investigate how this came through despite this; but hopefully this should be relatively rare combination of mishaps.

@dontcallmedom
Copy link
Member Author

so, here is what seemed to have happened:

  • the broken link error report was initially generated and manually reviewed on Sep 7; at that time, the anchor didn't exist in the contentEditable document - it was added in a commit on Sep 9
  • I only filed that particular report 2 days ago (since we've been slowly draining the list of reports generated back then to gauge the feedback from editors); that was done after I ran the script that is supposed to update reports to make sure they're still accurate, but I suspect that script has a bug that didn't catch the situation where there was only link in the report and that link is no longer broken

So there is definitely a bug to be fixed in the report updater, and also maybe a lesson that a delay between the manual review and the issue filing is something to be avoided in general.

@dontcallmedom
Copy link
Member Author

So there is definitely a bug to be fixed in the report updater

The underlying bug (#241) was filed and is now fixed

@tabatkins
Copy link
Member

Excellent, thanks!

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants