x/website: add regression tests HTML anchors of important docs don't change

[dolmen]

Previously the documentation for go doc links was at: https://go.dev/doc/comment#doc-links
Now it is at: https://go.dev/doc/comment#doclinks
The difference is in the hashref.

As now both links are in use (probably mostly by myself as I am a big promoter of godoc links), a redirect would be helpful.

[heschi]

cc @golang/tools-team

[zigo101]

Hashrefs in urls are not visible for servers. So the solution should be to add both IDs (doc-links and doclinks) for the target.

[hyangah]

@dolmen Can you help us find where doc-links hashref is used?

[dolmen]

I have used the hash ref in GitHub issues, PRs, Slack to tell people about godoc links.

[hyangah]

@dolmen I fully understand how frustrating it is when old links no longer work. But I want to understand is what prevents from starting to use the new #doclinks. Is it to make the historical comments in old github issues, prs, and slack conversation valid?

The source of this link is in https://github.com/golang/website/blob/5c08bf3ee65177ad7160bd55d4a04bc613d6af9b/_content/doc/comment.md?plain=1#L610

As shown, this is a simplified markdown file, which the server processes and renders to a html file. We cannot remove doclinks which will break other users. I am not sure what to associate the extra hashref with.

[dolmen]

If #doclinks is guaranteed to be stable from now, that's enough for my future use cases.

As the anchor seems to be defined in the document (and not by an algorithm) I expect that future breaking changes will be caught by code review. However a regression test on HTML anchors would be useful. Maybe this already somewhat exists if a test checks that links in the whole Go documentation are correctly resolved down to hashrefs.