Can we silence Link Checker Report if no errors?

[github-actions]

Full Github Actions output

[JonathanGregory]

Thanks a lot for fixing the errors, @sadielbartholomew and @erget! This one reports no errors. Previously, an issue wasn't opened if there were no errors. Can that be arranged? Otherwise each week we have to close the issue manually. Jonathan

[sadielbartholomew]

I am sure that can be arranged (or fixed, if it behaved like that before and somehow now doesn't do what we wanted originally). And I agree, it would be ideal to not be pestered by the reporting bot if there is no issue detected w.r.t links.

I am personally quite busy with various work so not sure I can find the time this week, but perhaps next week. Or if Daniel or somebody else can find time before then, they would be welcome to sort this.

[erget]

Hi @JonathanGregory yes, I remember that before there were no issues raised if errors weren't found... I think that may have been on the Conventions repository rather than here.

Upon looking into it though I've discovered another mystery: Why did this job complete without errors?

If I look into the action output, what it actually contains is a link to here. That's the job's output, and the job succeeded. However, looking at what the job actually produced, if I open the "Check links" section I see a number of files that passed or were excluded (good), and then a bunch of errors like this:

These are exactly the kind of errors that we want to catch with this job, and they're not caught. It's a mix of not being able to access servers due to expired certificates and pages that aren't available.

So the first question for me is why it succeeded in the first place.

I won't have time to pursue this this week, but it'll be helpful later on to come back to this analysis.

I recommend

• Figuring out why the link checker doesn't fail when it doesn't find links (I'm guessing that's a problem somewhere here where we're missing something. Probably the solution is something along the lines of this example usage for the "Links" workflow.
• Running the make issue step only if the link checking failed (may be fixed by looking above)
• Then we'd probably need a campaign, like we had for the Conventions document, to clear up the bad links that have crept in. This would be iterative.

Looks like whoever setup this job wasn't a master of GitHub Actions, and when I check who wrote those lines... It was me! I guess I shouldn't quit my day job ;)

[JonathanGregory]

Dear Daniel @erget

Thanks for looking at the report. Actually I think we've only ever checked links on the website repo (this one). We did fix all the missing links sometime last year, and the link checker was quiet for some months until the errors emerged that you, @sadielbartholomew and @davidhassell have resolved with updating the software. Therefore I am puzzled by this new crop of missing links - why weren't they detected before? Why do we have a link to YouTube?

Cheers

Jonathan

[larsbarring]

Some time ago, when we started thinking about the errors/warnings produced by this action, I, too, had a quick look into the deeper levels of the error reporting. From what I recall the errors that caught my eye were links that from a CF web site perspective looked pretty strange and suspicious. But they turned out to be related to documentation of presentations etc. at CF workshops and other external material, or the service we used to the social hour after each session. I think that it will impossible to actually check such links.

For example if there is a CF workshop presentation that links to some web material that subsequently has been withdrawn what do we do? Do we want to find where it may have moved and update the link (--no!) , do we edit the presentation to mute the link (--no), or do we remove the presentation altogether (--that would be counter-productive)? To me, a reasonable approach is that we limit the check, or at least the error reporting to our own links that we have in the CF website.

In fact, that is how I thought the action was already set up as those errors were not reported up front.

[erget]

I wouldn't try to sanitise those types of things either @larsbarring but there is the possibility to list certain links, files, or even folders AFAIK that the checker doesn't check. For me the presentation links would fit best if we don't check them as they're essentially independent material.

[sadielbartholomew]

To add to previous comments, regarding one question you raised that I can't yet see answered, @JonathanGregory:

Why do we have a link to YouTube?

This will be one or more links to the CF Conventions Training YouTube page (see e.g. on the Training homepage), which hosts training videos (a fairly new URL addition).

[JonathanGregory]

It seems that the link checker is happy, which is good, but on the other hand it is not quite satisfactory that it raises an issue every week to tell us it's happy, especially because it requires a human cron-like daemon to close them. 😈 The full output of the job is delivered to the issue as a zip, which currently says

[Full Github Actions output](https://github.com/cf-convention/cf-convention.github.io/actions/runs/7924620550?check_suite_focus=true)

i.e. nothing to report. How can we suppress this, if there are no problems found?

[JonathanGregory]

I'm closing this because #318 and #320 are dealing with the same issue.