First run in Gitlab CI causes an error

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

[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.

[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.