Replies: 1 comment
-
|
Updated the GitVersion file to trunk based. workflow: TrunkBased/preview1
major-version-bump-message: "^(Merged PR \\d+: )?(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test)(\\([\\w\\s-]*\\))?(!:|:.*\\n\\n((.+\\n)+\\n)?BREAKING CHANGE:\\s.+)"
minor-version-bump-message: "^(Merged PR \\d+: )?(feat)(\\([\\w\\s-]*\\))?:"
patch-version-bump-message: "^(Merged PR \\d+: )?(build|chore|ci|docs|fix|perf|refactor|revert|style|test)(\\([\\w\\s-]*\\))?:"
branches:
feature:
label: feature
pull-request:
label: beta{Number}Adding 'Merged PR' to the bump message let the version in main correctly update since we use squash merges and the message in Azure DevOps is 'Merged PR <whatever the PR title was>' It'd still be a nice to have for the PR title to be included when calculating the version, but I suppose I could do a workaround such as by adding a commit in the pipeline. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
We have a CD pipeline for pull requests that will run tests and deploy to a staging environment, upon completion we merge to the main branch for deployment to production environments.
We recently upgraded from GitVersion v5 to v6 and we used to use the Mainline mode.
Is there a way to correctly determine the version whilst taking into account the PR title?
e.g., a PR of
feat!: add something newis a breaking change so should increment the semver major version.This isn't exclusive to major versions either, it seems to just not increment the version at all. I'm assuming this is caused by
commit-message-incrementing: MergeMessageOnly. We have this set because of the squash merges we perform, if we didn't have it set the versions would be completely incorrect.This is the config we use right now:
Beta Was this translation helpful? Give feedback.
All reactions