Enforcing conventional commits in konveyor

[djzager]

We are beginning an effort in Konveyor CI and Release Engineering to automate the release process. Starting with konveyor/tackle2-hub#201, we will be introducing workflows to create releases for us with minimal (goal is no) human interaction.

One of the important components of that issue is the ability to automatically generate meaningful changelogs based on the commit history of the project and conventional commits are an excellent way for us to do this.

How does this impact me?

If we choose conventional commits, we will eventually expect all contributions to projects in the Konveyor community to abide by that convention.

Poll Question

Restating the Poll here where I still have emoji support.

Which variation of conventional commits should we use in konveyor?

1. Emojis please! For example fix -> 🐛, feat -> ✨ , feat! (breaking change) -> ⚠️
2. Emojis are weird. Just follow the conventions.
3. Please don't. If you are strongly against conventional commits for some reason, say so (and please include why and/or alternatives).

[savitharaghunathan]

✨

[jortel]

I'm not sure I understand the Emojis part of the poll. I did not see Emojis/styles mentioned in the conventional commit document. Can someone elaborate?

[djzager]

In the commit message itself.

[jortel]

So the choice is between:

feat: allow provided config object to extend other configs.

and

:sparkles: allow provided config object to extend other configs

Or something else?

[djzager]

Yes. Those are the choices and it wasn't until now that I realized I was missing a full example. My fault. Sorry about that.

[mansam]

Understood, thanks. I'm opposed to the emojis then. They don't show up well on my display and the meanings aren't intuitive to me.

[ibolton336]

I don't have a strong preference either way. When working on Patternfly, they used a similar approach for labeling PRs https://github.com/patternfly/patternfly-react/blob/main/CONTRIBUTING.md#pr-labels . I am FOR a more organized approach for labeling PRs - thanks for getting this together @djzager

[mturley]

@djzager after some time using them, I've decided I'm not a fan of the emojis.

• When used directly in a commit message, opening a PR defaults the title to using the actual unicode character and not the :sparkles: text, which fails CI.
• The meanings are not intuitive, I have to look them up often.

[mturley]

I'm using the CLI, and the commit message appears correctly in git log. I am using the gh CLI to create the PR, maybe that's the culprit.

[shawn-hurley]

Yeah, I don't know. I just wanted to add my experience.

For the discoverability problem, though, I don't have a good answer so, maybe we have to brainstorm that or consider switching

[djzager]

Going to see how well this works, if at all, and see where we go from there.

[mturley]

The issue I was seeing seems to have disappeared 🙃 and the PR template does help with discoverability. I'm okay with keeping it.

[shawn-hurley]

Love the idea of discoverability being in the template +100 @djzager