Skip to content
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

GitVersionTask 3.6.5 ignoring GitVersion.yml in project dir #1170

Open
asherber opened this issue Feb 25, 2017 · 8 comments

Comments

@asherber
Copy link

commented Feb 25, 2017

Given a VS solution with one or more projects that have the GitVersionTask NuGet package installed, GitVersion will look only in the solution dir for GitVersion.yml and will ignore any GitVersion.yml in the applicable project dir.

The docs at http://gitversion.readthedocs.io/en/latest/configuration/ say that I should be able to put the config file in any solution subdirectory, "in case you have a single repository for more than one project" and want to set different GitVersion parameters on each.

GitVersion CLI run from the project directory behaves correctly.

@asherber

This comment has been minimized.

Copy link
Author

commented Feb 25, 2017

See #1124 for more discussion, and especially #1124 (comment)

@gparlakov

This comment has been minimized.

Copy link

commented Oct 5, 2018

Hi all, I want to share a workaround that seems to be working:

  1. GitVersion uses $(Build.SourcesDirectory) to see where the sources are located - src
  2. We can change this using logging commands
  3. Workaround is to set the Build.SourcesDirectory before GitVersion task
  4. Then gitVersion uses the GitVersion.yml from the project folder (Build.SourceDirectory) and voila - works

After that you might want to roll back the change or not - depending on your need. For me it seems it is nice to scope down to the only nuget package from the collection of nuget packages in our nugetPackages monorepo.

@isen-ng

This comment has been minimized.

Copy link

commented Jan 28, 2019

Forgive me for being confused but how does this help in versioning per project in a single git repo?

-- root (where the .git is)
 +- project1
   +- gitversion.yml
 +- project2
   +- gitversion.yml
 +- gitversion.yml

If the git version ymls in the project subfolders are honored, can i have a different version for project1 and project2?

Like,

  • project 1 is at version 1.1.20-commit50
  • project 2 is at version 2.0.0-commit100

I believe the major and minor versions are based on tagging, the patch number could be by tag or commit number and the build number is based on commits since the last tag.

How do I set this up? Do I need to have a specific format for tags to say that that tag is meant for project1?

Is it possible to setup commit count tracking by folder too?

@arturcic arturcic removed bug labels Mar 7, 2019

@cytron201

This comment has been minimized.

Copy link

commented Apr 12, 2019

Any further comments on this scenario? I can see how @gparlakov workaround would handle the M.M.P versions as you could control these in the gitversion config scoped per solution, but @isen-ng point is that the pre-prelease tags will still need some way to be generated per solution.

I can't see any other way of achieving this for a mono-repo setup.

@stale

This comment has been minimized.

Copy link

commented Jul 11, 2019

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 11, 2019

@bdubaut

This comment has been minimized.

Copy link

commented Jul 22, 2019

This is exactly what I am trying to do right now, how can I help move this forward?

@stale stale bot removed the stale label Jul 22, 2019

@freePerep

This comment has been minimized.

Copy link

commented Aug 2, 2019

This is also for me exactly what I need for my project.

@garfbradaz

This comment has been minimized.

Copy link

commented Sep 10, 2019

Any news on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.