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

1. have an outdated main branch in your fork (e.g. make fork:main 5 commits behind upstream:main)
2. create an MR with one commit with a correct commit message (e.g. chore: testing bug)
   • MR to merge fork:feature1 -> upstream:main
3. locally update your main branch from upstream:main but don't push it to the fork:main
4. rebase your MR on the latest upstream:main and push that rebased MR into your MR branch fork:feature1
5. The commit lint will fail on the "Merge" commits

What is the current bug behavior?

• all commits between fork:main and fork:feature1 get linted (orange and green on the picture)

What is the expected correct behavior?

• only commits between upstream:main and fork: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.