Linting commits on MRs coming from forks might give false negative
Summary
The CI commit linting script might lint incorrect commits in the case that the MR is coming from a fork and the fork main
branch is out of date.
Steps to reproduce
-
upstream
- this repo -
fork
- forked repo in users' namespace
- have an outdated
main
branch in your fork (e.g. makefork:main
5 commits behindupstream:main
) - create an MR with one commit with a correct commit message (e.g.
chore: testing bug
)- MR to merge
fork:feature1
->upstream:main
- MR to merge
-
locally update your
main
branch fromupstream:main
but don't push it to thefork:main
- rebase your MR on the latest
upstream:main
and push that rebased MR into your MR branchfork:feature1
- The commit lint will fail on the "Merge" commits
What is the current bug behavior?
- all commits between
fork:main
andfork:feature1
get linted (orange and green on the picture)
What is the expected correct behavior?
- only commits between
upstream:main
andfork:feature1
should get linted (green on the picture)
Possible fixes
lint_commit:
stage: test
script:
- apt-get update && apt-get install -y git
- git fetch origin $CI_MERGE_REQUEST_TARGET_BRANCH_NAME && git checkout $CI_MERGE_REQUEST_TARGET_BRANCH_NAME && git checkout $CI_COMMIT_SHA
- cd scripts/commit-lint && npm ci
- node lint.js
rules:
- if: '$CI_MERGE_REQUEST_IID && $CI_PROJECT_VISIBILITY == "public"' # lint.js script makes an API call without authentication
when: always
The CI script uses git fetch origin
. When I wrote the script I thought this is always going to reference upstream
but on forks origin
=fork
repository.
The fix is to either hard-code the upstream
remote URL (git@gitlab.com:gitlab-org/gitlab-vscode-extension.git
) or use some CI environment variable that contains the correct remote.
Edited by Tomas Vik