-
Notifications
You must be signed in to change notification settings - Fork 652
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
[Feature] Introducing a new templating mechanism to support different workflows #3305
Comments
Comment from: #3357
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. |
🎉 This issue has been resolved in version 6.0.0-beta.1 🎉 Your GitReleaseManager bot 📦🚀 |
@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 |
@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. 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: I think it would be beneficial to set 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. |
how to skip to generate release on main and develop I need only release tag on release branch. |
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?
Question 2: What is your versioning mode?
...
Possible Implementation
Example 1: from GitFlow workflow
Example 2: from GitHub
Example 3: from scratch
The text was updated successfully, but these errors were encountered: