First run in Gitlab CI causes an error

[dmoonfire]

When using a boilerplate setup (I have a yeoman generator to create my novel projects), the very first CI run blows up when on Gitlab because $CI_BUILD_BEFORE_SHA is 0000000000000000000000000000000000000000. Since that is never a valid SHA in Git, it would be nice if the tool would look for that and just scan the entire branch or just skip it with a warning. (Or have a flag that lets you choose which one if it gets into that condition).

Expected Behavior

I use a boilerplate to set up my Gitlab repositories for my novels and stories. This is a semi-regular occurrence (1-3/month). Because I have it down to templates, I have commitlint in from the beginning of the chore: initial commit. However, when using it in a CI file, it fails because it is the first run of the CI.

image: dmoonfire/mfgames-writing-js:2.0.0

stages:
    - publish

publish:
    stage: publish
    only: [master]
    tags: [docker]
    script:
        - npm ci
        - npx commitlint --from=$CI_BUILD_BEFORE_SHA
        - npx semantic-release
        - npm run upload

When Gitlab CI starts, the environment variable is set to all zeros. The work-around is pretty simple, just make another change and push it up but that feels wrong because occasionally I forget that the first is always going to fail.

Current Behavior

 $ npx commitlint --from=$CI_BUILD_BEFORE_SHA
/builds/fedran/second-hand-dresses/node_modules/@commitlint/cli/lib/cli.js:114
	throw err;
	^
Error: fatal: Invalid revision range 0000000000000000000000000000000000000000..HEAD
    at DestroyableTransform._transform (/builds/fedran/second-hand-dresses/node_modules/git-raw-commits/index.js:83:30)
    at DestroyableTransform.Transform._read (/builds/fedran/second-hand-dresses/node_modules/readable-stream/lib/_stream_transform.js:184:10)

Affected packages

• cli
• core
• prompt
• config-angular

Possible Solution

• Add a new command-line option (--on-initial-run) have it either scan the entire branch (scan-branch) or ignore everything (ignore-previous).
• Pick one of the above and make it a default.

Steps to Reproduce (for bugs)

1. Create a new repository in Gitlab, turn on CI.
2. Check in a single .gitlab-ci.yml (see above).
3. Commit and push.

Context

• Just trying to avoid a consistent error in CI without adding a lot of noise to a CI file for a one-time occurrence (per repository).

Your Environment

Executable	Version
commitlint --version	7.6.1
git --version	2.20.1
node --version	8.16.1

[marionebl]

This is interesting, thanks for reporting. I think commitlint should not add Gitlab specific logic to cater for this. A user-land solution might be enough for this, something like:

# pseudo code
if [ $CI_BUILD_BEFORE_SHA == "0000000000000000000000000000000000000000" ]; 
  then; 
    npx commitlint --to=HEAD 
  else; 
    npx commitlint --from=$CI_BUILD_BEFORE_SHA; 
fi;

[screendriver]

This is interesting, thanks for reporting. I think commitlint should not add Gitlab specific logic to cater for this. A user-land solution might be enough for this, something like:

# pseudo code
if [ $CI_BUILD_BEFORE_SHA == "0000000000000000000000000000000000000000" ]; 
  then; 
    npx commitlint --to=HEAD 
  else; 
    npx commitlint --from=$CI_BUILD_BEFORE_SHA; 
fi;

This will fail with a Error: fatal: Invalid revision range when you force push a commit. Any idea how to solve that?

[oPiZiL]

This is interesting, thanks for reporting. I think commitlint should not add Gitlab specific logic to cater for this. A user-land solution might be enough for this, something like:

# pseudo code
if [ $CI_BUILD_BEFORE_SHA == "0000000000000000000000000000000000000000" ]; 
  then; 
    npx commitlint --to=HEAD 
  else; 
    npx commitlint --from=$CI_BUILD_BEFORE_SHA; 
fi;

This will fail with a Error: fatal: Invalid revision range when you force push a commit. Any idea how to solve that?

    if [ "${CI_BUILD_BEFORE_SHA}" = "0000000000000000000000000000000000000000" ]; then
      echo "commitlint from HEAD^"
      npx commitlint -x @commitlint/config-conventional -f HEAD^
    else
      echo "commitlint from ${CI_BUILD_BEFORE_SHA}"
      br=`git branch -r --contains ${CI_BUILD_BEFORE_SHA}`
      if [ ! -n $br ]; then 
        npx commitlint -x @commitlint/config-conventional -f HEAD^
      else
        npx commitlint -x @commitlint/config-conventional -f "${CI_BUILD_BEFORE_SHA}"
      fi
    fi

[alexandrebrg]

This is interesting, thanks for reporting. I think commitlint should not add Gitlab specific logic to cater for this. A user-land solution might be enough for this, something like:

# pseudo code
if [ $CI_BUILD_BEFORE_SHA == "0000000000000000000000000000000000000000" ]; 
  then; 
    npx commitlint --to=HEAD 
  else; 
    npx commitlint --from=$CI_BUILD_BEFORE_SHA; 
fi;

This will fail with a Error: fatal: Invalid revision range when you force push a commit. Any idea how to solve that?

    if [ "${CI_BUILD_BEFORE_SHA}" = "0000000000000000000000000000000000000000" ]; then
      echo "commitlint from HEAD^"
      npx commitlint -x @commitlint/config-conventional -f HEAD^
    else
      echo "commitlint from ${CI_BUILD_BEFORE_SHA}"
      br=`git branch -r --contains ${CI_BUILD_BEFORE_SHA}`
      if [ ! -n $br ]; then 
        npx commitlint -x @commitlint/config-conventional -f HEAD^
      else
        npx commitlint -x @commitlint/config-conventional -f "${CI_BUILD_BEFORE_SHA}"
      fi
    fi

I can confirm this little script is working as expected in gitlab-ci!

[dmoonfire]

Since I'm usually creating a new Git repo (about 3/month) and commitlint is one of the first things I set up, I ended up writing a little NPM utility to do it for me.

npx commitlint-gitlab-ci -x @commitlint/config-conventional

It seems to work fairly well for me, I've been messing with it for a little while and haven't had too many complaints.

[escapedcat]

@dmoonfire nice, you wanna add this to the community section?

If so, you can do that here:
https://github.com/conventional-changelog/commitlint/blob/master/docs/reference-community-projects.md

[yangm97]

Honestly I would recommend this way instead https://gitlab.com/gitlab-org/cluster-integration/auto-build-image/-/blob/615afe1b2092881dab2955fe5fc562bbc6fc577f/.gitlab/ci/test.gitlab-ci.yml#L246

It will check all commits from a given merge request.

[pjanuario]

Just a minor note I was using

    if [ "${CI_BUILD_BEFORE_SHA}" = "0000000000000000000000000000000000000000" ]; then
      echo "commitlint from HEAD^"
      npx commitlint -x @commitlint/config-conventional -f HEAD^
    else
      echo "commitlint from ${CI_BUILD_BEFORE_SHA}"
      br=`git branch -r --contains ${CI_BUILD_BEFORE_SHA}`
      if [ ! -n $br ]; then 
        npx commitlint -x @commitlint/config-conventional -f HEAD^
      else
        npx commitlint -x @commitlint/config-conventional -f "${CI_BUILD_BEFORE_SHA}"
      fi
    fi

It works on regular commit histories but if one execute a push force to remove a commit will fail since the previous build commit doesnt exists.

[S-Coyle]

In order for me to have commitlint run against all commits in an MR, as we would often have >1 commit per MR, I'm having to change the above to use --to HEAD^, i.e.

    if [ "${CI_BUILD_BEFORE_SHA}" = "0000000000000000000000000000000000000000" ]; then
      echo "commitlint to HEAD^"
      npx commitlint -x @commitlint/config-conventional --to HEAD^
    else
      echo "commitlint from ${CI_BUILD_BEFORE_SHA}"
      br=`git branch -r --contains ${CI_BUILD_BEFORE_SHA}`
      if [ ! -n $br ]; then 
        npx commitlint -x @commitlint/config-conventional -f HEAD^
      else
        npx commitlint -x @commitlint/config-conventional -f "${CI_BUILD_BEFORE_SHA}"
      fi
    fi

I'm concerned though that this will hit issues described above when people force push, etc. Will see how this works in practice, but if any advice please let me know.

EDIT: Finding issues unfortunately - seems running with --to HEAD^ always wants to run against the most recent 5 commits, even if some of those 5 commits already exist on the target branch and were not added as part of the MR.

[alessio-libardi]

Just to let you know, I'm not sure what is happening on the second run of a Gitlab CI job but during the first the GIT_DEPTH variable is used to clone only a subset of the repo.

In my case what was happening was that the CI was cloning the last 20 commits of the branch I was working on but the branch was 25 commits long.

The fix was simply to set the GIT_DEPTH variable to 0 for this particular job:

lint:commits:
  stage: lint
  needs: []
  only:
    - merge_requests
  variables:
    GIT_DEPTH: 0
  script:
    - npx commitlint --from="$CI_MERGE_REQUEST_DIFF_BASE_SHA"