It's really annoying to have notifications for failed jobs on personal branches, when the jobs are successful in the PR runs:
So the problem is when force-pushing against a personal branch, what do we compare against?
If we don't specify anything, the previous HEAD doesn't exist in the partial clone and so a total lint is performed, resulting in many errors that are filtered out on the PR (for good reason).
If we fetch upstream master and compare against that, we can have false positives due to non-conflicting code removed in upstream master. For example:
[8](https://github.com/selfhoster1312/matterbridge/actions/runs/22666101885/job/65698121743#step:6:30)
Error: bridge/matrix/matrix.go:778:10: do not define dynamic errors, use wrapped static errors instead: "fmt.Errorf(\"size isn't a %T\", size)" (err113)
return fmt.Errorf("size isn't a %T", size)
^
1 issues:
* err113: 1
Error: issues found
This line was removed upstream but is still present on the PR branch due to not producing a merge conflict that would prompt us to rebase on upstream master.
A compromise could be to look up the common ancestor between upstream master and the current branch:
- run: "git fetch upstream master"
- run: "git branch __ci_upstream_master FETCH_HEAD"
- run: echo "COMMON_ANCESTOR=$(git merge-base __ci_upstream_master ${{ github.ref }})" >> $GITHUB_ENV
...
args: >-
--build-tags=goolm --new-from-rev=${{ env.COMMON_ANCESTOR }}
This way, we compare against the commit from which the feature branch was forked, and any code removed upstream will not produce false positives. Any conflict will still prevent rebase&merge from the Github UI.
It's really annoying to have notifications for failed jobs on personal branches, when the jobs are successful in the PR runs:
So the problem is when force-pushing against a personal branch, what do we compare against?
If we don't specify anything, the previous HEAD doesn't exist in the partial clone and so a total lint is performed, resulting in many errors that are filtered out on the PR (for good reason).
If we fetch upstream master and compare against that, we can have false positives due to non-conflicting code removed in upstream master. For example:
This line was removed upstream but is still present on the PR branch due to not producing a merge conflict that would prompt us to rebase on upstream master.
A compromise could be to look up the common ancestor between upstream master and the current branch:
This way, we compare against the commit from which the feature branch was forked, and any code removed upstream will not produce false positives. Any conflict will still prevent rebase&merge from the Github UI.