[Feature] Introducing a new templating mechanism to support different workflows

[HHobeck]

Is your improvement request related to a problem? Please describe.
In the discussion of issue #2388 ([Feature] Root configuration should propagate to branches) I came up with the idea of introducing a new templating mechanism to support different workflows (see #2388 (comment)).

Detailed Description

In the current version of gitversion we are supporting only one default workflow with the name gitflow. If we want to support more workflows then we need to introduce a templating mechanism like maybe in kubernetes.

Context

This feature gives the user the possibility to easily switch from one workflow to another without specifying the hole configuration. Another use case might be to specify a workflow from scratch without using any predefined configurations. This mechanism can be integrated into the initialization wizard refactoring initiative of issue #3229 ([Improvement] Revamp init wizard for v6) very easily.

Initialization wizard questions:

Question 1: What kind of workflow you are using?

• GitFlow
• GitHubFlow
• CustomFlow from scratch

Question 2: What is your versioning mode?

• ContinuousDeployment
• ContinuousDelivery
• Mainline

...

Possible Implementation

Example 1: from GitFlow workflow

workflow: GitFlow/v1
assembly-versioning-scheme: MajorMinorPatchTag
assembly-file-versioning-scheme: MajorMinorPatchTag
assembly-informational-format: '{MajorMinorPatch}+{Sha}'
mode: ContinuousDeployment
branches: {
    "release": {
      "tracks-release-branches": true
    }
}

Example 2: from GitHub

workflow: GitHub/v1
assembly-versioning-scheme: MajorMinorPatchTag
assembly-file-versioning-scheme: MajorMinorPatchTag
assembly-informational-format: '{MajorMinorPatch}+{Sha}'
mode: ContinuousDeployment
branches: {
    "main": {
      "tracks-release-branches": true
    }
}

Example 3: from scratch

workflow: ''
...

[harryjohn-dev]

Comment from: #3357

I think this is a brilliant idea. It would also open up for the community to add/suggest built-in templates as pull requests in future. For example, I could suggest the above config as a "trunk-based development with release branches" workflow and others can easily make use of it.

Additionally, it would make onboarding much easier, in that the configuration clearly says "GitHubFlow" - rather than showing modes that "work well" with the various workflows.

[arturcic]

🎉 This issue has been resolved in version 6.0.0-beta.1 🎉
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀

[HHobeck]

@sheppyh May I ask you for your help? I would like to integrate a base template (GitVersion configuration) for a trunk based workflow. Because I'm not using the trunk based workflow by myselfe I thought you are the right person to ask. :)

This configuration is for the GitHubFlow workflow:

assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatch
label-prefix: '[vV]?'
major-version-bump-message: '\+semver:\s?(breaking|major)'
minor-version-bump-message: '\+semver:\s?(feature|minor)'
patch-version-bump-message: '\+semver:\s?(fix|patch)'
no-bump-message: '\+semver:\s?(none|skip)'
label-pre-release-weight: 60000
commit-date-format: yyyy-MM-dd
merge-message-formats: {}
update-build-number: true
semantic-version-format: Strict
branches:
  main:
    label: ''
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    regex: ^master$|^main$
    source-branches:
    - release
    tracks-release-branches: false
    is-release-branch: false
    is-mainline: true
    pre-release-weight: 55000
  release:
    label: beta
    increment: None
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    regex: ^releases?[/-]
    source-branches:
    - main
    - release
    tracks-release-branches: false
    is-release-branch: true
    is-mainline: false
    pre-release-weight: 30000
  feature:
    mode: ContinuousDelivery
    label: '{BranchName}'
    increment: Inherit
    regex: ^features?[/-]
    source-branches:
    - main
    - release
    - feature
    pre-release-weight: 30000
  pull-request:
    mode: ContinuousDelivery
    label: PullRequest
    increment: Inherit
    label-number-pattern: '[/-](?<number>\d+)'
    regex: ^(pull|pull\-requests|pr)[/-]
    source-branches:
    - main
    - release
    - feature
    pre-release-weight: 30000
  unknown:
    mode: ContinuousDelivery
    label: '{BranchName}'
    increment: Inherit
    regex: .*
    source-branches:
    - main
    - release
    - feature
    - pull-request
ignore:
  sha: []
mode: ContinuousDelivery
label: '{BranchName}'
increment: Inherit
prevent-increment-of-merged-branch-version: false
track-merge-target: false
track-merge-message: true
commit-message-incrementing: Enabled
regex: ''
tracks-release-branches: false
is-release-branch: false
is-mainline: false

[harryjohn-dev]

@HHobeck sure happy to jump in and help! Apologies I missed your comment.

I think I settled on this in the end, but it's been a while and I still haven't pushed this to live in our main repositories. You can use this as a base config for trunk-based development.

#3357 (comment)

branches:
  main: 
    # Match nothing
    regex: ^\b$
  develop:
    # Development is done on master
    regex: ^master$|^main$
  release:
    source-branches:
      - main
    mode: ContinuousDeployment

I'm picking this up again now so can test. I'm also yet to test your suggestions in 6.x as you mentioned here:

#3357 (comment)

I think it would be beneficial to set semantic-version-format option to Loose also in this config as you suggested.

Additionally, some documentation to go with the template for the workflow might be nice to talk about some conventions and gotchas that I ran into - which I'm happy to write if it would be useful.