Lechee check on PR is checking whole portal, instead of just modified content

[georgik]

The check should be localized only to added content, because otherwise the merge might fail in case of malfunction of url in unrelated content.

[f-hollow]

#107 limits link checking by pr-check-links to the PR diffs only.

[f-hollow]

There were numerous false positives in recent PRs.

Analyzing false positives yielded the following results:

• #149 and #167
  • Dump links from the commit after which the feature branch was created (as opposed to checking out current main and dumping the links)
• #164
  • Mimicking the pr-link-check workflow locally yielded false positives differing from the ones reported by GitHub Actions.
  • Among the mentioned false positives, the link https://docs.google.com/forms/d/e/1FAIpQLSeqeP4L90wLu0om38q-wvxKYKI1_Y4Hf4T928NQI8LBW4mHhQ/viewform?embedded=true was present in .lycheeignore, yet it still triggered false positives, escaping the question mark ...\?embedded... solved the problem.
  • Mimicking the pr-link-check workflow outside of the company network didn't yield any false positives!
  • While mimicking false positives in this and other PRs, I eventually discovered that lychee dumps only part of links at times (some files are skipped?). lychee's Troubleshooting section suggests "breaking the check into multiple lychee runs with different exclusion/inclusion rules". It might help resolve such false positives.

Actions required:

• Update the pr-link-check workflow to have the links dumped from the commit after which the feature branch was created

  git checkout -b <feature-branch>-main
  git reset --hard HEAD (discard all feature branch commits)
  dump all links using lychee

[f-hollow]

Summary of work done

#107

This PR implements link checking in diffs. To be more precise, the links that exist in main's latest commit are added to .lycheeignore, then the links that exist in the contributor's feature branch are checked for validity.

#180

On a number of occasions, broken links from the main branch were reported.

It was decided to dump links from main only until the commit at which a feature branch was forked (base commit). That would provide more predictable results.

#366

It appeared that main branches in forks were sometimes not rebased for a while, and the feature branches was rebased on upstream/main directly. As a result, the base commit was determined incorrectly (latest but still outdated common commit on main and feature). For this reason, the broken links from the most recent commits on main seeped through.

This PR changes the branch against which the base commit is determined from hard-coded origin/main to the branch defined by the CI environment variables TARGET_REPO_URL and TARGET_BRANCH. These variables are set to the upstream/main branch.

Unrelated links reported #

The same links from old commits still occasionally pop up in different PRs. During work on #379, it became clear that even though files containing false positives are not changed in PRs directly, Hugo still updates them. More information can be found in #379 and further investigation is needed.

[f-hollow]

Another case of false positives from old commits in #459.