Conventional Changelog CLI

[mahyarmirrashed]

I am thinking, that if we have Husky, Lint Staged, Commitlint, and Conventional Changelog CLI, that would make the whole CI process much easier for you @PKief . What are your thoughts. I am very new to all of the above but I am willing to learn and give it a shot.

[mahyarmirrashed]

We may have to rebase the whole repository with the updated commit messages that adhere to Commitlint standards. Or, we can squash all previous commits (I would not recommend this). Then, we can easily generate the changelog.

[mahyarmirrashed]

If you use the GitHub CLI, you can then also have it lint from there as well. Though, I think there is something that you can add on GitHub directly to do the same tasks as Commitizen.

[ryanmattos]

We may have to rebase the whole repository with the updated commit messages that adhere to Commitlint standards. Or, we can squash all previous commits (I would not recommend this). Then, we can easily generate the changelog.

Rebase the entire repo? I guess it wouldn't be a good idea. Just imagine the commitlint being like a common linter, since a project is already started and you decide to use it, you won't lint all project files, you will lint gradually the files you have changed.

[ryanmattos]

We may have to rebase the whole repository with the updated commit messages that adhere to Commitlint standards. Or, we can squash all previous commits (I would not recommend this). Then, we can easily generate the changelog.

Rebase the entire repo? I guess it wouldn't be a good idea. Just imagine the commitlint being like a common linter, since a project is already started and you decide to use it, you won't lint all project files, you will lint gradually the files you have changed.

ps: I don't know if I get what you meant right, but if it is what i think it is, i don't think that'd be the only way to do that

[mahyarmirrashed]

We may have to rebase the whole repository with the updated commit messages that adhere to Commitlint standards. Or, we can squash all previous commits (I would not recommend this). Then, we can easily generate the changelog.

Rebase the entire repo? I guess it wouldn't be a good idea. Just imagine the commitlint being like a common linter, since a project is already started and you decide to use it, you won't lint all project files, you will lint gradually the files you have changed.

ps: I don't know if I get what you meant right, but if it is what i think it is, i don't think that'd be the only way to do that

If you have the chance, take a look at Commitlint. Basically, it requires that all commits made follow a certain format. That format is then used by other programs like standard-changelog to look through the entire Git commit message history and determine the current version of the software as well as automatically generate a changelog.

[PKief]

Thank you for your contribution and please excuse the late reply. I currently have it set up so that the changelog is generated automatically, which has definitely saved me time. Since all changes are currently only squashed via PR I can control quite well how the squashed commit messages - and thus the entries in the changelog look like. From my point of view this is sufficient for now. I also don't want to overcontrol how the commit messages should look like.