bug: failure in GitLab with "Error: fatal: Invalid revision range"

[abitrolly]

Steps to Reproduce

I am not sure if it is dup of #885 or not, but I've got this failure here https://gitlab.com/gitlab-community/modelops/applied-ml/code-suggestions/ai-assist/-/jobs/7430104908

$ npm install --save-dev @commitlint/config-conventional @commitlint/cli
added 125 packages in 9s
28 packages are looking for funding
  run `npm fund` for details
$ echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js
$ npx commitlint --from="$CI_MERGE_REQUEST_DIFF_BASE_SHA" --help-url 'https://www.conventionalcommits.org/en'
file:///builds/gitlab-community/modelops/applied-ml/code-suggestions/ai-assist/node_modules/@commitlint/cli/lib/cli.js:127
        throw err;
        ^
Error: fatal: Invalid revision range 6e97dc894774a3d16b9d6abf5bf762ee240abd08..HEAD
    at Transform.transform [as _transform] (/builds/gitlab-community/modelops/applied-ml/code-suggestions/ai-assist/node_modules/git-raw-commits/index.js:100:36)
    at Transform._write (node:internal/streams/transform:171:8)
    at writeOrBuffer (node:internal/streams/writable:570:12)
    at _write (node:internal/streams/writable:499:10)
    at Writable.write (node:internal/streams/writable:508:10)
    at Socket.ondata (node:internal/streams/readable:1007:22)
    at Socket.emit (node:events:532:35)
    at addChunk (node:internal/streams/readable:559:12)
    at readableAddChunkPushByteMode (node:internal/streams/readable:510:3)
    at Readable.push (node:internal/streams/readable:390:5)
Node.js v22.5.1


The commit from "Invalid revision range" is here https://gitlab.com/gitlab-community/modelops/applied-ml/code-suggestions/ai-assist/-/commit/6e97dc894774a3d16b9d6abf5bf762ee240abd08 and it precedes the MR, so I am not sure what this error is about.

Current Behavior

No response

Expected Behavior

Expected actionable error message.

Affected packages

• cli
• core
• prompt
• config-angular

Possible Solution

No response

Context

No response

commitlint --version

i don't know

git --version

i don't know

node --version

v22.5.1

[abitrolly]

Okay. #885 (comment) pinpoints the problem.

The default git depth in GitLab pipelines is 20 (https://docs.gitlab.com/ee/ci/pipelines/settings.html#limit-the-number-of-changes-fetched-during-clone).

And there are exactly 20 commits in my MR.

So the solution to my problem is to remove git depth limitation in the lint job (https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/merge_requests/1143).

  variables:
    GIT_DEPTH: 0

The proper fix on commitlint side is to detect this condition, and show user the fix. On GitLab side - to ensure that MR default clone depth always includes parent commit.

[escapedcat]

Might be already good to add a comment to the docs first

[abitrolly]

@escapedcat #4105

[abitrolly]

Opened an issue in GitLab for long term fix https://gitlab.com/gitlab-org/gitlab/-/issues/474701

[janbiasi]

@abitrolly I think this issue is "resolved", right? There's nothing we could do to prevent this issue on GitLab except the documentation change which happened in a2f27fa.

[abitrolly]

@janbiasi is there is a smart way to detect how many commits does MR contain, that would be the best fix to put into docs. The chances that GitLab issue will fix itself are low.

[janbiasi]

@abitrolly according to your comment and the GitLab Docs it is 20 - this is also already stated in the docs (see below). Hence my comment to close this issue as we can't do more than document that.

commitlint/docs/guides/ci-setup.md

Lines 139 to 141 in 0c58997

	GitLab limits `git clone` depth to
	[20 commits by default](https://docs.gitlab.com/ee/ci/pipelines/settings.html#limit-the-number-of-changes-fetched-during-clone).
	Setting `GIT_DEPTH: 0` removes this limitation, so `commitlint` can check larger MRs.

cc @escapedcat

[abitrolly]

@janbiasi the commitlint can request any revision length. Chances that users will discover this issue are low, so regardless of documentation, the unnecessary traction will still disrupt people workflow.

If it is impossible to detect the exact number of commits in GitLab MR, commitlint can fail gracefully. But I believe the git branchpoint information is still present in some CI environment variable. So the logic could be:

if err.Error() == "Error: fatal: Invalid revision range" && ci == "gitlab"{
  if undefined(branch_commits) and len(log) == 20 {
    exit("Error: commit XXXXX is out of default GitLab fetch range (20), see https://github.com/conventional-changelog/commitlint/issues/4103 how to increase it")
  }

  if len(log) < len(branch_commits) {
    exec(`git fetch --depth ' + len(branch_commits))
    retry
  }
}

[janbiasi]

@abitrolly each CI handles this differently, so you would need to implement workarounds for each CI and their corresponding git implementation (= not commitlint). As an example; with GitHub you can't request a further depth in commits than specified within checkout action unless your providing a custom GH token with specific access. This would lead to inconsistencies in terms of CI usage, which is more confusing and prone to invalid setups than the current state.

Additionaly - at least in my opinion - this is not within the commitlint scope, as the commits are a prerequisite outside of commitlint itself and provided by git.

I'd be happy to hear what your opinion is @escapedcat