fix: commitlint docker image isn't tagged with latest/version

[Clockwork-Muse]

Expected Behavior

That a fully tagged docker image is available, with a version tag and the latest tag.

Current Behavior

The CI documentation now includes the following:

stages: ["lint","build","test"]
lint:commit:
  image:
    name: registry.hub.docker.com/commitlint/commitlint:latest
    entrypoint: [""]
  stage: lint
  script:
    - echo "${CI_COMMIT_MESSAGE}" | commitlint

(Just merged yesterday, thank you!)
... however as of this writing the available tags are:

Which means that the version/latest tags aren't present.

Affected packages

• cli
• core
• prompt
• config-angular

Possible Solution

If my reading of the github actions is correct, performing a release/making a tag should kick off the required CI run and publish the required tags.

Steps to Reproduce

`docker pull registry.hub.docker.com/commitlint/commitlint:latest`

Context

I'm trying to set up an Azure DevOps pipeline, focusing on using container images, because trying to do it via node/npx doesn't seem to be working.

Unfortunately AzDO requires images generally not have an ENTRYPOINT entry, which prevents the image from running as-is.
(And a few other restrictions, but the image should meet them otherwise)

commitlint --version

N/A

git --version

N/A

node --version

N/A

[escapedcat]

@kaiehrhardt you wanna tackle this? 😊

[kaiehrhardt]

@escapedcat We have to publish a new version (tag).

https://github.com/conventional-changelog/commitlint/blob/master/.github/workflows/container-build.yml#L32
https://github.com/docker/metadata-action#latest-tag

@Clockwork-Muse For now, you could go with the edge tag (==master).

[escapedcat]

@escapedcat We have to publish a new version (tag).

Sorry I'm not (yet) familiar with this. Should/can we do this manually (via dockerhub) now?

https://github.com/conventional-changelog/commitlint/blob/master/.github/workflows/container-build.yml#L32

I assume we can add a latest tag here?

https://github.com/docker/metadata-action#latest-tag

Is says "It will be generated by default (auto mode) for: [...]". But in our case it's not being created by default, right? Do we want to change this?

@Clockwork-Muse For now, you could go with the edge tag (==master).

Happy for a PR

[AdeAttwood]

For my understanding, @kaiehrhardt will the current configuration, will this set the latest docker tag to an alias of the most recent version tag.

IMO I don't think it's a good idea to set latest to our master branch. I think edge is a much better name.

@escapedcat I think all you need to-do is publish a new release tag, I think you use lerna

[kaiehrhardt]

For my understanding, @kaiehrhardt will the current configuration, will this set the latest docker tag to an alias of the most recent version tag.

IMO I don't think it's a good idea to set latest to our master branch. I think edge is a much better name.

@escapedcat I think all you need to-do is publish a new release tag, I think you use lerna

accurately described :)

Keep the issue open, i will add some container related docs to be more precisely.

[escapedcat]

@escapedcat I think all you need to-do is publish a new release tag, I think you use lerna

So now the docker image is using the latest commit on master instead of the last official released version?
And this part means we always update the image on schedule (every night?) and tags but not on master updates?
So in the future it will be aligned with released versions? Or not because we build it every night?

Sorry, but missing some understanding here for now.

Keep the issue open, i will add some container related docs to be more precisely.

Thanks for your work @kaiehrhardt

[kaiehrhardt]

So now the docker image is using the latest commit on master instead of the last official released version?

yes, with the shared tag edge

And this part means we always update the image on schedule (every night?) and tags but not on master updates?

yes. we could change this behaviour if we want to. This is a pattern which is mainly used for security fixes of the base image.

So in the future it will be aligned with released versions? Or not because we build it every night?

It may happen that these images diverge.

git	build trigger	image
latest version (vx.x.x)	tag	registry.hub.docker.com/commitlint/commitlint:latest registry.hub.docker.com/commitlint/commitlint:vx.x.x
master branch	schedule (nightly)	registry.hub.docker.com/commitlint/commitlint:edge registry.hub.docker.com/commitlint/commitlint:$githash
feature branch	branch	registry.hub.docker.com/commitlint/commitlint:$branchname registry.hub.docker.com/commitlint/commitlint:$githash

[escapedcat]

we could change this behaviour if we want to. This is a pattern which is mainly used for security fixes of the base image.

If that's how most people use it I'm good with that, thanks.

Regarding a new latest tag just for sake of this image I would rather skip this for now and the first official latest tag would than be when we merge and release: #3644
Would that be ok?

[AdeAttwood]

@escapedcat can we not push out a patch version before we go to the next major version. I think changing too much at once will be harder to debug if things go wrong.

[escapedcat]

Sure, alright, will do within the next days

[Clockwork-Muse]

@escapedcat I think all you need to-do is publish a new release tag, I think you use lerna

This is what I was trying to get at. I don't know what your release schedule is at, though...

@Clockwork-Muse For now, you could go with the edge tag (==master).

Yeah, once I figured out there wasn't a latest I just tried that, but just figured I should bring it up.
Unfortunately I can't use the image, because AzDO is weird, but that's on them, not on you.

[escapedcat]

Released https://github.com/conventional-changelog/commitlint/releases/tag/v17.7.2
Does this help?

Looks like we got a latest

[Clockwork-Muse]

Yup, that should do it.

[escapedcat]

Yay, you're free to close this issue. Thanks everyone!