<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Cicd on shione</title><link>https://bensaber.net/blog/tags/Cicd.html</link><description>Recent content in Cicd on shione</description><generator>Hugo</generator><language>en-US</language><copyright>Copyright © 2024, renken.</copyright><lastBuildDate>Mon, 10 Apr 2023 12:47:00 +0100</lastBuildDate><atom:link href="https://bensaber.net/blog/tags/Cicd/index.xml" rel="self" type="application/rss+xml"/><item><title>Conventional commits</title><link>https://bensaber.net/blog/conventional-commits.html</link><pubDate>Mon, 10 Apr 2023 12:47:00 +0100</pubDate><guid>https://bensaber.net/blog/conventional-commits.html</guid><description>I recently came across conventional commits and I find the idea very interesting and practical. The commit message style is similar to my subjective style except it&amp;rsquo;s standardized and most importantly parsable. The end goal is to automatically generate changelogs following keep a changelog.
I found a couple of tools which does this.
commitizen commitizen is good if you use the default config. However, as soon as you derive from the latter, you&amp;rsquo;d need to write your own customized parsing config which I found to be somewhat difficult to write considering how sometimes commitizen crashes if your config is invalid.</description></item></channel></rss>