awesome-devops VS release-please

I would start with awesome devops and drill down there to which tools and projects are open source and in go. I know that Terraform is in go, Docker itself is in go, some projects that I use like Telegraf are in go too, but a comprehensive list of all tools that can be used by devops, that are open source and in go may be huge. Is better to get a very partial list and pick from there the ones you find more interesting, both in mission and in code.

github.com/wmariuss/awesome-devops

Not necessarily, it just depends on how invested you are in the CI/CD pipeline for any given project, your preferences regarding self-hosting vs. cloud, and the amount of time you have to dedicate to the subject.

Strictly speaking, any tool or set of tools that allow you to trigger building & deploying/publishing artifacts in response to source control commits can be used to build a CI/CD pipeline. One could write bash scripts linked to a cron job that pulls a remote repository every n minutes and then performs some scripted actions to integrate changes between branches before building & publishing the artifact to a local SFTP server.

If you prefer a more mature solution with better documentation however, there is a (non-exhaustive) list of CI/CD tools on this awesome-devops list:

https://github.com/wmariuss/awesome-devops#continuous-integr...

Using Conventional Commits ⭐ as a standard for your commit messages, makes Semantic Versioning 🔖 as easy as can be, with tools like Conventional Changelog 📄 Standard Version 🔖 and Semantic Release 📦🚀

Conventional Commits

We've covered everything about writing well-formatted and structured code without worrying too much about it anymore. The only part we haven't explored yet is linting commit messages. Commitlint will help us here. It allows you to configure any rules you want for the commit message, but we're going to use the Conventional Commits specification, one of the most popular conventions you'll find.

Commit Management with Conventional Commits: The Conventional Commits methodology is adopted to maintain a clear and structured record of changes with the help of commitlint.

Validate if the commit titles adhere to the Conventional Commits Specification in Merge requests.

Check out https://www.conventionalcommits.org

FYI there is already a popular tool that does just this with a very similar name: https://github.com/googleapis/release-please

The feature commit should have a clear defined message - Don't re-invent here - There exists a fairly used and accepted convention called Conventional Commits, so we are going to use that.