[linters] Check link-anchor for # stutter

[chalin]

This adds a link-anchor hash-stutter check for an error that seems to creep in now and again, for example:

• [editorial] compatibility/opentracing.md: fix anchor, ## -> # #2312
• URL anchor fix: ## -> # #2075

NOTE: The build for this PR will fail (demonstrating that the check is working) until #2312 is merged.

/cc @austinlparker @tedsuo @carlosalberto

[chalin]

Here is an example of the check at work (excerpt from https://github.com/open-telemetry/opentelemetry-specification/runs/5052423559?check_suite_focus=true):

$ make markdown-link-check
FILE: ./specification/compatibility/opentracing.md

  37 links checked.

Error: link anchor contains double ## on these line(s):
504:[Link](../trace/api.md##specifying-links) functionality. This information
make: *** [Makefile:33: markdown-link-check] Error 1

Error: Process completed with exit code 2.

[chalin]

Of course this is a simple syntactic check that might, down the line, register false-positives but IMHO we can face that situation if/when it arises. In the meantime, it'll be nice to catch anchor-hash stutters on PR submission.

[chalin]

#2312 has been merged, I've rebased. The check is still failing -- I'm investigating now.

[chalin]

Ok, so this is the current behavior:

• If there is a double hash in an anchor, the check will fail
• If there are invalid links, they will be reported by markdown-link-check, but the check will pass. This was the behavior before this PR -- presumably because there were too many false positives(?). If this was an oversight and you'd like the check to fail when invalid links are discovered, then all we need to do is change the ; at the end of this line to &&.

Let me know.

[Oberon00]

I think you found a bug here. 👍

[chalin]

I was fixed via #2323 -- see https://github.com/open-telemetry/opentelemetry-specification/pull/2323/files#r801649513.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[chalin]

@carlosalberto et all: any consideration being given to this extra check?

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[chalin]

Hi @carlosalberto et all: before I spend time resolving conflicts on this PR I wanted to know if you saw value in this extra check? If not, we can continue to detect it in the same way I've been doing it before, that is, when I build the spec through the website. I'm ok either way.

[carlosalberto]

Hey @chalin

If this was an oversight and you'd like the check to fail when invalid links are discovered, then all we need to do is change the ; at the end of this line to &&.

As @Oberon00 mentioned, I think this was a bug.

(Sorry for the delayed answer!)

[chalin]

Thanks for the feedback @carlosalberto and @Oberon00.
So do you want me to submit a separate fix, or simply update (resolve the conflicts) and resubmit this PR?

[carlosalberto]

Updating and re-submitting it is enough with me ;)

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[chalin]

Since the identified issue was fixed in #2323, I'm going to close this PR since I no longer thing that it is worth the extra check of anchor-hash stutters.