fix: git no longer available in container, throws error when using --from-last-tag

[jeohist]

Steps to Reproduce

We are using commitlint in our GitLab CI pipelines. With the upgrade to 19.6.0 we noticed unexpected failures, which turns out to be caused by Git no longer being available in the container after #4185.

Config:

commitlint:
  image: commitlint/commitlint:19.5.0
  script:
    npx commitlint --from-last-tag --to "$CI_COMMIT_SHA" --verbose

Current Behavior

Resulting error:

file:///usr/local/lib/node_modules/@commitlint/cli/lib/cli.js:132
        throw err;
        ^
Error: spawn git ENOENT
    at ChildProcess._handle.onexit (node:internal/child_process:[28](https://gitlab.rnd.mendix.com/devx/ci-templates/-/jobs/5153376#L28)4:19)
    at onErrorNT (node:internal/child_process:477:16)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'spawn git',
  path: 'git',
  spawnargs: [
    'describe',
    '--abbrev=40',
    '--always',
    '--first-parent',
    '--long',
    '--tags'
  ]
}
Node.js v18.20.5

Expected Behavior

Commits since last tag should be grabbed and linted.

Affected packages

• cli
• core
• prompt
• config-angular

Possible Solution

Install Git in the container, not just in the build layer

Context

No response

commitlint --version

19.6.0

git --version

N/A

node --version

v18.20.5

[sathieu]

Fixed by #4197. When will this be released?

[escapedcat]

This should already have been released via:
https://github.com/conventional-changelog/commitlint/actions/runs/12042210146

Can you confirm this?

[sathieu]

This should already have been released via: https://github.com/conventional-changelog/commitlint/actions/runs/12042210146

Can you confirm this?

No. Latest version is v19.6.0. It doesn't include #4197.

[escapedcat]

Not too familiar with this.
Isn't this job using master?: https://github.com/conventional-changelog/commitlint/blob/master/.github/workflows/container-build.yml
I thought the docker build are independent from the release. Maybe I'm wrong /cc @skycaptain

[sathieu]

What I meant by release is a GitHub release and a Git tag, not a Docker push.

[escapedcat]

:( Can't publish because it wasn't a fix or feat, which I thought isn't needed because it's not adding anything commitltint itself.
Now creating an empty fix commit to make a publish work: #4200

Wondering how this could have been solved better.
Maybe we need feat/fix for container/docker stuff as well in this case? Although it doesn't change commitlint itself? 🤷‍♂️

[escapedcat]

Hm, doesn't help. Lerna is not picking up "the fix".

$ lerna publish --conventional-commits
lerna notice cli v6.4.1
lerna info current version 19.6.0
lerna info Looking for changed packages since v19.6.0
lerna success No changed packages to publish
✨  Done in 3.15s.

Ugh, yeah, I guess we didn't run into this before. Lerna always checks for changes in the packages. And this wasn't an issue until now.

Any ideas how to solve this?

[skycaptain]

First of all, I apologize for the inconvenience caused by #4185. We should have implemented checks to run unit tests in the container image created on the same branch. Currently, it seems that commitlint/commitlint:latest and commitlint/commitlint:19.6.0 are affected by this issue.

I see several possible solutions:

1. Restore the original image by copying a working image ref over latest and 19.6.0. For example, copy the build from 49ba56d (the parent commit of feat(container): switch to Alpine container #4185) using crane: crane copy commitlint/commitlint:49ba56d commitlint/commitlint:latest
2. Copy master tag (which includes the fix from build: fix install git in container #4197) over latest and/or 19.6.0 using crane: crane copy commitlint/commitlint:master commitlint/commitlint:latest
3. Force lerna to do a release. While I'm not familiar with lerna, my experience with semantic releases shows that empty commits don't work on monorepos because no workspace files are changed and these tools release per-workspace (as you already found out ourself). As a last resort, I typically add a // RELEASE_BUSTER: 1 comment in some workspace file, commit it as a fix:, and remove it with a chore: afterward. I haven’t tested this, but this might be even possible in a single PR, making it a no-op while still forcing the semantic release tool to do a release, as there would be a fix commit in the unreleased history.
4. The least desirable option (not an option IMHO, but just for completeness): Advise users to use commitlint/commitlint:master or commitlint/commitlint:19.5.0 until the next release. On a side note (but obviously a very sarcastic one, my apologies): pinning images to specific digests would prevent these kinds of pipeline breakages as users on 19.6.0 would be able to revert to an earlier (working) digest.

[escapedcat]

Thanks for your feedback! No worries, this happens. People can always revert to a previous container I guess.

Going with option 3 would be fine with me for the current situation.

In general I would like to know how this could be handled in the future.
A release of commitlint should focus on the functionality of commitlint, not on a container build. But when we need to update something related to the container, how to release it then?

I guess there are similar projects out there. Maybe we can check how they handle this?

[sathieu]

Restore the original image by copying a working image ref over latest and 19.6.0

Please never override version image tags. Those should be immutable to avoid unexpected result.

[escapedcat]

Now it was possible to create a new release. Have a look if this works please:
https://github.com/conventional-changelog/commitlint/releases/tag/v19.6.1

Still wondering how to handle such situation in the future.