mark whole run as --todo

[khoivan88]

Hi,

Thank you for this very useful library. I wanted to incorporate your tool into snowpack build on top of 11ty build. I was able to check all internal link successfully with your tool. Following your advice that all external links could also be check but not fail the build process, I'm struggling to mark all failed or skipped link for external as ok for the npm build process. Would you know how I can achieve this? Thank you very much!

Here is a portion of my package.json

...
"scripts": {
    "clean": "del _site",
    "start": "npm run clean && snowpack dev",
    "build": "snowpack build",
    "postbuild": "npm run links-internal && npm run links-external",
    "links-internal": "hyperlink -pri --root _build --canonicalroot https://example.com/ --todo 'fonts.gstatic' --todo 'file.myfontastic' _build/*.html | tap-spot",
    "links-external": "hyperlink -pr --root _build --canonicalroot https://example.com/ --todo '//' _build/*.html | tap-spot"
  },
...

Right now, my trick is to use // as to mark all of external links so the hyperlink check does not fail my npm run. However, I am just wondering if there is a better way?

Thank you very much!

[Munter]

I think I would recommend never to check external links in your build process, using the -i flag as you already have.

For the external lin check I would recommend to run it as a manual audit once in a while, not marking them as TODO, but just letting them fail.

I haven't found good CI support for a concept of a warning that lets you continue the build, but collect all the warnings for a report that can be acted upon, so for now I think the manual audit is the way to go for external links to avoid getting your CI pipeline blocked

[khoivan88]

thank you very much for your answer!!

[Ryuno-Ki]

I haven't found good CI support for a concept of a warning that lets you continue the build, but collect all the warnings for a report that can be acted upon, so for now I think the manual audit is the way to go for external links to avoid getting your CI pipeline blocked

Since @khoivan88 brought that topic up in the 11ty Discord before, let me chime in :-)

Alternatively to failling external links, wouldn't it be possible to mark them as skipped? This way, there could be a list of „skipped” tests, which could act as a list of external links to check.
(I'm using https://www.screamingfrog.co.uk/seo-spider/ for semi-automated manual checks, but 500 limit is hard).
Ideally, I'd expect a plain text with a link per line.

Although, knowing which page contained that link could be helpful if I want to fix it.
I'm not only interested in 4xx or 5xx but also in 301 (Moved Permanently) or similar.

[Munter]

@Ryuno-Ki In TAP semantics SKIP means that the test should never be run in the first place. Hyperlink honors this by not even making the request. This is the feature you want to use to speed up your tests if you don't care about the result.

What @khoivan88 did with marking a test as TODO is the correct way to get the behavior you describe. The test will be run, the request is made, but any FAIL will be marked as TODO. Again, the problem here is that you need to manually inspect the CI output because no CI service that I'm aware of picks up on those TAP semantics. They all just rely on exit codes, which are quite binary.

I am definitely interested in finding a way where the external link check can be made useful as a CI task. But I think it would require some sort of report gathering and then having o pipe it to a different command that submits a webhook, or something along those lines. I feel that sort of work is a never-ending scope explosion, which doesn't overlap much with the core hyperlink functionality.

If you want to change the output from hyperlink you can do so with a custom TAP reporter. This is one of the reasons I chose this format. You could use such a reporter as a filter to get just the TODO's. Here's where I make decisions on test statuses in tap-spot: https://github.com/Munter/tap-spot/blob/master/index.js#L48-L63

Hyperlink does indeed report linking to a permanent redirect (301) as a failure