filter on tags on prefix or regex, to make it possible to use multiple git versions in one repository

[santo2]

Context

We are trying to merge a solution that build nuget packages from one repo to another. This repo already has a tagging structure for other nuget packages. we do not want to mix up these tags. The most obvious thing for us, seems to be able to have a filter, in which we can state a prefix or regex, so that a certain git version task, will only analyze the ones having this prefix or regex.

Other issue that we see: the analysis of the already existing tags takes about 10 minutes, because we have a lot of them. having the filter possibility, just as command git tag -l "prefix*" has, would make the analysis a lot quicker. Or is there any other way?

Solution that we think would help:

specify a prefix, that is used both for tagging and for filtering during the analysis to specify which git tag will have to be added.

Or am I missing a feature that already does this?

[brendankowitz]

I'm looking for something similar, it looks like something like this might exist already: https://github.com/GitTools/GitVersion/blob/master/src/GitVersionCore/Model/Configuration/Config.cs#L41

tag-prefix: prefixRegex

[dagophil]

You can put a GitVersion.yml into each project folder and use tag-prefix: '...'. For example, this folder structure should work well:

MyMonoRepo/
| FooLib/
| | GitVersion.yml (with tag-prefix: 'Foo-v')
| | [...]
| BarLib/
| | GitVersion.yml (with tag-prefix: 'Bar-v')
| | [...]

If you now run GitVersion inside the FooLib directory, it only considers Foo-v* tags and if you run it inside the BarLib directory, it only considers Bar-v* tags.

However, you will run into problems if you checkout tagged commits for one package and try to get the version of the other package. For example, if you checkout Foo-v1.2.3, GitVersion cannot compute the version of BarLib.

[asbjornu]

GitVersion operates on the basic principle of having one versionable entity per repository. Monorepo and similar methodologies is explicitly not supported. If you manage to get GitVersion to work in your environment regardless, please consider that a hack and not something you can be confident GitVersion will support in the future.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[sebastienwarin]

Hello there,

FYI, I have forked GitVersion in Oct,2019 (based on the version 4.0), to add a new IVersionFilter called "Path filters" : https://github.com/sebastienwarin/GitVersion/commits/feature/pathfilters to include or exclude commit based on the file paths.

To use it, you have just to add in the GitVersion files the new section "paths" to include (or exclude) paths under the section "ignore" :

ignore:
  paths:
    include: 
      - MyProjectFolderA/

When GitVersion calculate the next version, the path filter check each commit to ignore those that not modifiy any files within the list.

You can add paths to "include" or to "exclude".

ignore:
  paths:
    include: 
      - MyProjectFolderA/
      - MyProjectFolderB/
    exclude: 
      - MyProjectFolderC/

I use this forked version since Oct, 2019 for all my projects, It works like a charm. I also suggest to use this with the "tag-prefix".

Take an example : you have 1 git repository with 2 projects/directories (to make it simple) :

• MyLib/ : .NET class lib
• MyWebApp/ : ASP.NET web app

You create one GitVersion config file (.yml) per project :

MyLib.yml :

mode: ContinuousDeployment
tag-prefix: "MyLib/"
ignore:
  paths:
    include: 
      - MyLib/

MyWebApp.yml :

mode: ContinuousDeployment
tag-prefix: "MyWebApp/"
ignore:
  paths:
    include: 
      - MyWebApp/

Then :

• GitVersion.exe /config MyLib.yml : to generate the version for the class lib project
• GitVersion.exe /config MyWebApp.yml : to generate the version the web app project

In the build pipelines, tag MyLib/X.X.X and MyWebApp/X.X.X after each build.

Enjoy!

[asbjornu]

That looks interesting, @sebastienwarin. If you are able to rebase those changes on HEAD of main, add support for file globbing to the path specs, tests for the functionality and accompanying documentation, I'd welcome a pull request adding this functionality to GitVersion.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[marc-mueller]

The described feature looks very good and is actually exactly what we need. Is there any ETA when a PR would be ready?

[asbjornu]

@marc-mueller, someone would have to take @sebastienwarin's code, rebase it against GitTools:main and submit a PR.

[marc-mueller]

I can have a look on how complex this will get, but currently I cannot guarantee to take care of it (too many things on my personal backlog). Do you already have a globbing library in use in the project? Is there some information available how you do your testing? Do you test against a real repository or is it mocked?

[asbjornu]

@marc-mueller, yes we have IGlobbingResolver in place already. You can have a look at the existing ignore tests for inspiration:

https://github.com/GitTools/GitVersion/blob/c9df1c4f4b3063dbddb295673e28b96542e420a8/src/GitVersion.Core.Tests/IntegrationTests/IgnoreBeforeScenarios.cs#L14-L33

[marc-mueller]

Thanks for the info. I tried porting the source code to the latest master. I'm currently struggling with the Path Diffs. The current master is not compatible with the original code.

I thought that creating an additional Diff Method on the IGitRepository would hide the implementation details appropriately. But currently I am struggling how to get a reference to the IGitRepository from the PathFilter. The PathFilter is used in IgnoreConfig but also there I'm not sure how to inject the IGitRepository.

From my current understanding, the easiest way would be to have a reference to IGitRepository from the GitVersionContext which is available in the Filter implementation. Is this a valid solution approach?

Current work in progress: https://github.com/GitTools/GitVersion/compare/main...marc-mueller:feature/pathfilter

[asbjornu]

@marc-mueller, please submit a draft pull request so we can discuss the code and figure out its direction within it.

[marc-mueller]

https://github.com/GitTools/GitVersion/pull/2862

[leonids2005]

Hello there,

FYI, I have forked GitVersion in Oct,2019 (based on the version 4.0), to add a new IVersionFilter called "Path filters" : https://github.com/sebastienwarin/GitVersion/commits/feature/pathfilters to include or exclude commit based on the file paths.

To use it, you have just to add in the GitVersion files the new section "paths" to include (or exclude) paths under the section "ignore" :

ignore:
  paths:
    include: 
      - MyProjectFolderA/

When GitVersion calculate the next version, the path filter check each commit to ignore those that not modifiy any files within the list.

You can add paths to "include" or to "exclude".

ignore:
  paths:
    include: 
      - MyProjectFolderA/
      - MyProjectFolderB/
    exclude: 
      - MyProjectFolderC/

I use this forked version since Oct, 2019 for all my projects, It works like a charm. I also suggest to use this with the "tag-prefix".

Take an example : you have 1 git repository with 2 projects/directories (to make it simple) :

• MyLib/ : .NET class lib
• MyWebApp/ : ASP.NET web app

You create one GitVersion config file (.yml) per project :

MyLib.yml :

mode: ContinuousDeployment
tag-prefix: "MyLib/"
ignore:
  paths:
    include: 
      - MyLib/

MyWebApp.yml :

mode: ContinuousDeployment
tag-prefix: "MyWebApp/"
ignore:
  paths:
    include: 
      - MyWebApp/

Then :

• GitVersion.exe /config MyLib.yml : to generate the version for the class lib project
• GitVersion.exe /config MyWebApp.yml : to generate the version the web app project

In the build pipelines, tag MyLib/X.X.X and MyWebApp/X.X.X after each build.

Enjoy!

this is exactly what we need. Any chance it will be incorporated into main version? Sorry, I see there is some progress :) ...looking forward to get it :)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs.