How to configure GitVersion to fit our needs

[maxraab]

Suppose you have a big community and many contributions. Every contribution starts with a feature branch from master and after it's finished gets merged back to master. (Normal GitHub Flow). The main difference is the release stragegy:

If a release is sheduled - a new release branch (e.g. 8-1-stable, 8-2-stable, ...) is created from current master. From this time only some contributions gets cherry picked from master into the stable branch. All release candidates (e.g. 8.1-rc1, 8.1-rc2, ...) where tagged on this stable branch.

If the Version is ready to ship, the Version gets tagged but the release branch will not merged back into master. (To support up to 10 versions at the same time).
From this time, the commits on master should have a version similar to: "next-version"-pre.

[asbjornu]

@maxraab Could you please provide a more visual example of how your Git graph looks like? A simple Web Sequence Diagram would do.

[maxraab]

As you can see, we have no tags directly in master.

/cc @asbjornu

[DanielRose]

You will need to use the feature #832 for this to work (currently only in the preview releases).

For configuration (see http://gitversion.readthedocs.io/en/latest/configuration/): Mark the master branch as is-develop. You will also need a custom branch name and tag-number-pattern, or change the name of your stable branches (i.e. release branches) to a standard release-1.1 or release/1.1

[maxraab]

Thank you for your response.

I don't get it.

Is it possible to get one of these szenarios working?
I've added two files (szenario1.cs, szenario2.cs) with our testcases.

[DanielRose]

I couldn't test your scenario, but try a GitVersion.yml with the following contents:

branches:
  master:
    tag: pre
    is-develop: true
  releases?[/-]:
    tag: rc

[gep13]

@maxraab @DanielRose NOTE: In order to verify any changes that you make in the configuration file, you will need to clear the GitVersion cache, which you can find here:

i.e. within the .git folder of your repository. If you don't clear this out, you won't get any different results.

NOTE: This has been corrected in a newer version of GitVersion, but just wanted to point it out in case you don't see any changes in the asserted version number.

[maxraab]

This is exactly the configuration i've tested in Szenario2.css`: See here

2 / 5 tests will fail because:

Testname: CommitsInFeatureBranchWithSingleFeatureBranch should be "0.10.1-BranchD.1+23" but was "0.1.0-BranchD.1+23"

and

Testname: CommitsInFeatureBranchWithMultipleFeatureBranches should be "0.10.1-BranchE.1+23" but was "0.1.0-BranchE.1+23"

It would be nice to have the branchname in the version string.

[maxraab]

@gep13 Thank you.

I assume that every testcase will get a fresh git repository.

[DanielRose]

Okay, if I understand those tests correctly (they are difficult to read because of all the helper methods which create and/or checkout branches, make commits, etc.):

You created a branch release/0.10 with some commits. Thus, the master branch (marked with is-develop) should pick up the version number 0.10. Then you are in a feature branch BranchD. In that branch, it does not pick up the version number 0.10.

That looks like a bug to me.

[maxraab]

Yep, that's the point.
I thought it would be better to encapsulate some logic to methods to not mess up the test.

[maxraab]

@DanielRose The problem I discovered is, that our feature branches has no branch-configuration. (It is not possible to force this in a big community).

Then there is no branch-configuration found in BranchConfigurationCalculator.GetBranchConfiguration() and a default configuration will be created. After ConfigurationProvider.ApplyBranchDefaults() applies a default config, isDevelop is set to false.

If this default configuration would have isDevelop = true, all tests (including my demo-tests) will pass.

[DanielRose]

There are a bunch of default configurations for various branches. You can see the current config (including all defaults) if you run gitversion /showconfig. Feature branches have a default name of features?[/-]. So if you use such a naming convention for your feature branches (ex. feature/A, feature/B) that could work.

@JakeGinnivan At least as far as I understand it, the feature-branches should not need is-develop for this to work. Or did I misunderstand that?

[maxraab]

@DanielRose As mentioned before, we are a big community with a lot of contributors and we cannot force them all to use such naming conventions like feature/A. This is only possible for release-Branches because all of them are maintained by the core team.

[gep13]

@maxraab said...
@DanielRose As mentioned before, we are a big community with a lot of contributors and we cannot force them all to use such naming conventions like feature/A. This is only possible for release-Branches because all of them are maintained by the core team.

There is only so much that GitVersion can do in terms of recognising branches, and applying the necessary configuration to the branches. If you are not in a position to control the naming conventions that are used, then perhaps GitVersion isn't the right tool for your needs.