Make compare_to useful with forks
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
What's the problem?
From a quick skim (and search) through #293645 (closed) and !90968 (merged), it looks like the fact repos can be forked was not considered when coming up with rules:changes:compare_to. As a result, the current solution is broken for that use case: if a project sets compare_to: main (for instance), and the repo is forked, and a new branch is pushed with some work, the main branch of the fork will be used, which can only work if everyone who has a fork always pushes every commit from upstream main into their fork's main before pushing their branch.
This is obviously not possible for a number of reasons, but the main one is that even if we could accept such a cost (it can only work with a very fixed set of developers, which is the opposite of how open-source works), people will forget.
GitLab will not even be able to create a pipeline if the fork doesn't have the reference yet (such as a project where the main branch used to be called master and that's what the fork has instead of main).
Potential solutions
There needs to be a way to make compare_to: track the upstream repo when the current repo is a fork.
Since I understand that you might want to keep bug-compatibility, you might need to add a new key instead of compare_to:, eg. compare_to_upstream:.
I would argue that since the feature is currently unusable in forks, the solution could be as simple as adding "if this is a fork, the reference is in the upstream repo" in find_compare_to_sha in lib/gitlab/ci/build/rules/rule/clause/changes.rb.