Is there a way to use GitVersion in monorepos?

[AlexPykavy]

Hi,

I'm wondering if GitVersion is used in monorepo scenarios. I mean the case when we develop many packages/modules under the same repository but want to keep separate versioning.

I've developed a toy example how this can be implemented and decided to ask if it'll make sense to extend the docs to describe this or another good approach for the use case I described.

[asbjornu]

Recommended reading: #1268, #2436 (comment), #2441 (comment), and finally #4420. Your example does not seem to ignore anything done in project-a in project-b or vice versa. Isn't that going to wrongly affect the version number in both projects?

[AlexPykavy]

@asbjornu, thank you for the references!

Your example does not seem to ignore anything done in project-a in project-b or vice versa.

True. The trick I use is to leverage filtering on the pipeline level, so the pipelines which are used to version our projects are triggered only when files from the corresponding folders are actually changed. I admit that it's quite fragile, but I don't see a good alternative at the moment. Hopefully when Feature: Support ignoring (filtering) paths in git tree implementation is complete, it'll be possible to do what I need using only GitVersion configuration.

I have a question about the #2436 (comment) comment from 2020. Is this statement still relevant? I mean that GitVersion won't support monorepo as a standard use case.

[asbjornu]

As long as we get code contributions improving GitVersion's monorepo support from people actually using monorepo, I'm not against it. What I'm against is the external demand that the core contributors (@arturcic, @HHobeck, and myself) implement and maintain monorepo support in GitVersion, considering none of us are using monorepo ourselves.

#4420 is thus a move in the right direction, but it needs more tests so we don't risk regressions when GitVersion undergoes refactorings and other changes in the future.