Per-folder configuration for monorepo support

[AndreiMarukovich]

One way of using Git repository is to put multiple projects in the subfolders of one repository (monorepo). In this case it is desirable to version these projects independently, based on the commits in the corresponding folders.

How feasible is to introduce a additional mode for GitVersion to track not only the branches, but folders as well?

[asbjornu]

Duplicate of #1170.

[Jaykul]

This is not a duplicate of #1170 because it's not enough to support multiple gitversion.yml files

[Nakzz]

Any update on this?

[asbjornu]

Nope, @Nakzz. I don't understand or need the use-case and no one else who does have contributed code to implement it.

[ichbestimmtnicht]

Well I have a use case for you: The https://moleculer.services Framework. It has a monorepo structure by default and you build services within folders that then get bundled together. So it makes little sense to split up the repo but helps to have different internal versions from a development side for a compatibility matrix when working with multiple teams at the same time for example.

[asbjornu]

It’s not the lack of use-cases that is the limiting factor in this being implemented and supported by GitVersion, it’s the lack of code contributions from people like you who are using monorepos, @ichbestimmtnicht.

The current maintainers of GitVersion does not use, nor recommend the use, of monorepos. Personally, I view it as an anti-pattern. Therefore, we have no incentive to implement support for monorepos. As a matter of fact, since we aren’t using monorepo ourselves, the incentive to not support monorepo is much greater than to support it.

However, if someone who wants to champion monorepo support into GitVersion steps up, contributes the necessary code and tests as well as future maintenance of said feature, I’m not against merging it.

But so far, no such code have been contributed and therefore GitVersion does not support it.

[jwittner]

As a follow up, I was able to version multiple things out of a single repository by having separate GitVersion-<API>.yml files and running the tools with explicit references to which API I was computing. Working out well in several repositories that have multiple versioned things in them. I also add prefixes to the version tags, e.g. <API>-v1.0.0.

Unfortunately the patch versions still progress for an API even if there were only changes affecting other APIs, but this hasn't been much of a practical issue.

I think this achieves the goal of what you propose, though I have to admit I expected to be able to do it in the repository's configuration file as well. It would have probably saved me a bunch of time. =)

[cmeyertons]

@jwittner do you mind specifying how you made the explicit references to API?

I can't get it to work w/ tag-prefix and, after reading and re-reading the docs, am unsure of how you did so.

If you could provide a sample config file, that would be fantastic :) I'm sure it would help the next person stumbling across this thread!

Here's my config:

next-version: 0.1.0
increment: Inherit
# continuous-delivery-fallback-tag: ci
tag-prefix: 'MyAPI'
commit-message-incrementing: Disabled
update-build-number: true

[jwittner]

For a version tagged e.g. MyApi-v1.0.0, you'd want something like the below. I've added customized bump messages for myapi as well, though I see you have it disabled in your config.

I'm invoking the tooling in PowerShell through the dotnet cli and using the JSON output rather than the /output buildServer flag to do my own setup (due to conversion from legacy system).

Note: I've seen bad behavior from next-version.
Note: I've seen bad behavior if you create tags with versions containing 'prerelease' strings.

tag-prefix: 'MyAPI-v'
major-version-bump-message: '\+myapi-semver:\s?(breaking|major)'
minor-version-bump-message: '\+myapi-semver:\s?(feature|minor)'
patch-version-bump-message: '\+myapi-semver:\s?(fix|patch)'
no-bump-message: '\+myapi-semver:\s?(none|skip)'

[jwittner]

The commit message incrementing is awesome for having your feature branches predict the next version.

Our projects also have slightly different message regex than above, which checks for specific strings known to be in the Pull Request template so that we can control the final version through the Pull Request description itself which has made thing so easy now!

major-version-bump-message: '(\+myapi-semver:\s?(breaking|major)|\[x\] an API breaking change in MyAPI)'
minor-version-bump-message: '(\+myapi-semver:\s?(feature|minor)|\[x\] an API addition to MyAPI)'

[AlexeyRaga]

@jwittner has it been already implemented somewhere?

[jwittner]

@jwittner has it been already implemented somewhere?

Sorry, has what been implemented? I don't think per folder configuration in a single GitVersion.yaml has been added, but my work around above details how to support different versions from a single repo via different GitVersion-<api>.yaml files. This is working well for us in several repos in practice.