Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
santo2 opened this issue Oct 27, 2020 · 18 comments · May be fixed by #4420
Open
Labels
Milestone

Comments

@santo2
Copy link

santo2 commented Oct 27, 2020

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?

@santo2 santo2 added the feature label Oct 27, 2020
@brendankowitz
Copy link

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
Copy link

dagophil commented Dec 3, 2020

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
Copy link
Member

asbjornu commented Dec 3, 2020

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
Copy link

stale bot commented Mar 19, 2021

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.

@stale stale bot added the stale label Mar 19, 2021
@sebastienwarin
Copy link

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!

@stale stale bot removed the stale label Apr 2, 2021
@asbjornu
Copy link
Member

asbjornu commented Apr 6, 2021

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
Copy link

stale bot commented Jul 9, 2021

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.

@stale stale bot added the stale label Jul 9, 2021
@stale stale bot closed this as completed Aug 18, 2021
@marc-mueller
Copy link

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

@asbjornu
Copy link
Member

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

@asbjornu asbjornu reopened this Sep 24, 2021
@stale stale bot removed the stale label Sep 24, 2021
@marc-mueller
Copy link

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
Copy link
Member

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

[Test]
public void ShouldFallbackToBaseVersionWhenAllCommitsAreIgnored()
{
using var fixture = new EmptyRepositoryFixture();
var objectId = fixture.Repository.MakeACommit();
var commit = Substitute.For<ICommit>();
commit.Sha.Returns(objectId.Sha);
commit.When.Returns(DateTimeOffset.Now);
var config = new ConfigurationBuilder()
.Add(new Config
{
Ignore = new IgnoreConfig
{
Before = commit.When.AddMinutes(1)
}
}).Build();
fixture.AssertFullSemver("0.1.0+0", config);
}

@marc-mueller
Copy link

marc-mueller commented Sep 29, 2021

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: main...marc-mueller:feature/pathfilter

@asbjornu
Copy link
Member

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

@marc-mueller marc-mueller mentioned this issue Sep 29, 2021
5 tasks
@marc-mueller
Copy link

#2862

@leonids2005
Copy link

leonids2005 commented Dec 22, 2021

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
Copy link

stale bot commented Apr 16, 2022

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.

@stale stale bot added the stale label Apr 16, 2022
@arturcic arturcic removed the stale label Mar 4, 2023
@HHobeck HHobeck added this to the 6.x milestone Apr 2, 2023
@arturcic arturcic added stale and removed stale labels Jun 30, 2023
@github-actions
Copy link

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.

@github-actions github-actions bot added the stale label Sep 29, 2023
@arturcic arturcic removed the stale label Sep 29, 2023
@arturcic arturcic added stale and removed stale labels Oct 30, 2023
@HHobeck HHobeck modified the milestones: 6.x, 7.x Feb 6, 2024
@smietanka
Copy link

smietanka commented Feb 7, 2025

@sebastienwarin wow, really cool feature that we would like to have. Is there any plan to manage this feature into GitVersion?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
10 participants