Ensure new content introduced doesn't use hard links to jenkins.io

[NotMyFault]

Description:

Linking to other pages within the documentation is done like link:/projects/jcasc/. In this example, the target URL rendered on jenkins.io leads to https://www.jenkins.io/projects/jcasc/
Using the first figure ensures pages are resolved against the domain URL, regardless of the domain they are deployed at.
For example, local deployment, netlify preview, etc.

Problem:

Occasionally, people use hard links like https://www.jenkins.io/projects/jcasc/ in AsciiDoc files. If you preview your changes made on netlify, the target URL leads to jenkins.io and redirects outside the domain you are currently at.

Solution:

I'm open for technical drafts and ideas. I didn't think too much about it yet, but a make target that checks if a file modified matches a certain condition could do the trick.
No reason to overcomplicate this.

[hervelemeur]

Not sure why there were some recent blogposts with hard coded links, but since this PR adding a script in the Makefile preventing them, this shouldn't happen anymore: #5899

[NotMyFault]

Not sure why there were some recent blogposts with hard coded links, but since this PR adding a script in the Makefile preventing them, this shouldn't happen anymore: #5899

Oh, I approved the PR and forgot about it, great 🤦🏻
Looks like Mark's solution implemented matches with my solution proposed, nice. I guess we can disregard my issue then.

Not sure why there were some recent blogposts with hard coded links

git grep -l https://www.jenkins.io -- content/[a-zA-Z]**/*.adoc does match content/myCoolDirectory/index.adoc only.
I assume it's not supposed to be non-recursively, is it?
Although I don't use make check because I'm blocked by #6038