1

When it comes to generate versions using conventional commits from a repo that contains only one python package things are easy, you just need to use one tool that loops through all the repo commits and compute the version by parsing these conventional commits (break-change=major, feat=minor, fix=patch), so far so good.

What happens in a monorepo that contain multiple products that needs to track different versions? Let me put you an example, the azure sdk for python for instance, how would you use conventional commits & tooling effectively for this type of repos?

I'd like to come up with a solution that obviously scales up, for instance, it'd be able to automatically compute the version of the different monorepo products at the pipeline level without any developers interaction. Some of the points I'm trying to clarify here would be:

  • Branch name semantics
  • Conventional commits semantics (is this a good example where you use the optional scope to reference your different products)
  • Versioning tooling
  • Pipelines

But anyway, my question is simple, is there any best practice to follow for this one?

BPL
  • 9,632
  • 9
  • 59
  • 117
  • Why the `git` tag? I don't see the answer being different for other version control systems. – Anders Munch Nov 06 '22 at 11:24
  • You've got a point there, reason being because git maybe gives you certain features to leverage than other revision control systems when it comes to examine file paths in the commits. But anyway, I've changed the `git` tag by `version-control` instead – BPL Nov 06 '22 at 11:26

1 Answers1

1

Here is an example of how we do it with Reliza Hub (out tool): https://github.com/relizaio/rebom/blob/master/.github/workflows/github_actions.yml

Idea:

  1. Every push generates a release per branch that is stored in the tool.
  2. The tool is also responsible for producing next release version based on chosen schema (while we do that, this step is optional though, as you can use a different tooling or approach here).
  3. Next, for every repo within monorepo you check latest successful commit from the tool and compare it with the actual commit you have, basically this code:
            difflines=$(git diff $last_commit..$GITHUB_SHA ./ | wc -l)
            if [ "$difflines" != "0" ]
            then
              dobuild=true
            fi
  1. As per above, only do build if there is a diff for this specific directory (repo).
  2. If the build succeeds, record success status and other required metadata back to the tool.
  3. Rinse and repeat for each next code push.

There may be other tools that do that but the key point is you need some external storage that would keep track of successful builds mapped to corresponding commits. Some people also try to overload git tags to achieve that - but this rarely works for monorepos.

taleodor
  • 1,849
  • 1
  • 13
  • 15