Skip to content

feat: build and publish OCI image #3423

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
4 tasks
shanduur opened this issue Nov 18, 2022 · 10 comments
Closed
4 tasks

feat: build and publish OCI image #3423

shanduur opened this issue Nov 18, 2022 · 10 comments

Comments

@shanduur
Copy link
Contributor

Expected Behavior

I want to be able to include conventional-changelog/commitlint in my CI, instead of doing custom images or installing commitlint on every run.

Current Behavior

There is no docker image right now.

Affected packages

  • cli
  • core
  • prompt
  • config-angular

Possible Solution

Include build script in the CI, that builds multi arch OCI images (e.g. using buildah.io).

Context

I am trying to run CI that verifies if commits are properly formatted. I am using primarily Drone CI and GitLab CI. GitLab CI allows me to do something like this:

commitlint:
  image: docker.io/library/node:17-alpine
  before_script:
    - apk add --no-cache git
    - npm install --save-dev @commitlint/config-conventional @commitlint/cli
  script:
    - npx commitlint --from ${CI_MERGE_REQUEST_TARGET_BRANCH_SHA} --to HEAD --verbose
  only:
    - main
    - merge_requests

However this takes a lot of time, as we need to install git and commitlint every time we want to run CI checks.

@escapedcat
Copy link
Member

Hey @shanduur , happy for a PR or suggestions how to tackle this.
Maybe @AdeAttwood has some input.

@AdeAttwood
Copy link
Member

I don't have any weight in the decision in this, but I will comment on the issues we faced before.

This is a very specific use case in the fact it is using @commitlint/config-conventional. Short of adding every config known, there is no good way to select what config you want to use. We had this issue when crating the orb, we were asking what config the user wants to use then installing it. Then is it really any different to what you are already doing?

I do see value in adding the most popular config into the image but, with a lot of the misconception of this project when I was heavily involved, it is not “conventional commits” it's commitlint. There were a lot of people using with JIRA and many other commit formats and custom rules.

Ultimately, in the end, we ended up making our own internal docker image for this reason. No one else would want to use our slightly not conventional-commit config, and we don't want all the conventional-commit configs. I am still actively using some commit lint packages, but find that I want a very opinionated way to commit.

I personally like the idea, just could never make it work for me and everyone.

@kaiehrhardt
Copy link
Contributor

kaiehrhardt commented Nov 29, 2022

This is a very specific use case in the fact it is using @commitlint/config-conventional. Short of adding every config known, there is no good way to select what config you want to use. We had this issue when crating the orb, we were asking what config the user wants to use then installing it. Then is it really any different to what you are already doing?

A possible solution could be to provide multiple images with only one config in it.

I do see value in adding the most popular config into the image but, with a lot of the misconception of this project when I was heavily involved, it is not “conventional commits” it's commitlint. There were a lot of people using with JIRA and many other commit formats and custom rules.

As a starting point, we could provide a image with @commitlint/config-conventional. Sure maybe there are some advanced usecases, where teams build their own images, but i think that's not the usecase you want to match with a default docker image.

@AdeAttwood
Copy link
Member

As a starting point, we could provide a image with @commitlint/config-conventional.

I think this is a good idea.

Sure maybe there are some advanced usecases, where teams build their own images

This is currently where I am at.

This leads to the question of who will build and maintain this image. I don't feel like I can be the one to build and maintain something that I will not be using. In the past this has not work well, it seems to go to the bottom of the priority list and the users who actually use it suffer.

@kaiehrhardt
Copy link
Contributor

This leads to the question of who will build and maintain this image.

I could build the image and maybe the ci (not rlly familiar with circleci). Maintenance could be a problem. We could try to automate the biggest maintenance problems like base images / package versions with tools like renovate or dependabot.

@escapedcat
Copy link
Member

@shanduur @AdeAttwood any feedback to the current PR?: #3431
It's not my really my topic tbh

@AdeAttwood
Copy link
Member

@shanduur @AdeAttwood any feedback to the current PR?: #3431 It's not my really my topic tbh

@escapedcat we will need to sort out some logistics. I will be in contact with you soon, I don't even have Slack installed ATM. It's on my list to sort this out, will get to it shortly.

@raghunathd8
Copy link

Do we have any updates/news regarding official docker image/OCI? I could not find any updates since Dec.2022 therefore would like to followup. Thx!

@escapedcat
Copy link
Member

Do we have any updates/news regarding official docker image/OCI?

There are some updates in the PR: #3431

@escapedcat
Copy link
Member

Image was published

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

5 participants