Reputation: 2715
I'm a DevOps engineer building CI processes for teams in Azure DevOps. One of the teams have a workflow of continuously creating libraries for reuse in other projects. This workflow starts with an automatic process that:
main
branch that includes build validation with the above pipeline.So now each time a developer will issue a pull request in one of these libraries the tests pipeline will run, and only if passed successfully can the pull request be completed.
Now about versioning: The intent is that on each merge to main
, the commit will be tagged with a major
.minor
.
What I first thought to do is create another release
pipeline (Not Release as in Azure Release Pipelines - just a regular pipeline) that is triggered upon push to main
, so once the pull requests is merged, it will be triggered, and will just tag the current commit and push it.
What I thought to do is to use the syntax
name: <major_somehow>.$(Rev:r)
And then use this to tag the commit. So the minor version will be automatically incremented in each merge to master.
My problem is, that I want to create some mechanism to let the developers somehow flag that they want to increment a major version.
I first thought maybe to agree on a convention that they'll not something like [major]
in the description of the pull request. But that doesn't really help me because I need to know this in the "release" pipeline.
Can someone advise?
Upvotes: 0
Views: 4396
Reputation: 1486
You can do this with the counter in a yaml pipeline. The counter will be incremented by each build of the pipeline, if you switch the project version in another branch Azure DevOps increments the counter separately.
Thus you can build versions se.g. in the following order 0.3.4, 0.2.0, 0.2.1, 0.3.5, 0.2.2, ...
variables:
- name: 'projectVersion'
value: '0.2'
- name: 'runNumber'
value: $[counter(variables['projectVersion'], 0)]
- name: 'buildver'
value: '$(projectVersion).$(runNumber)'
Upvotes: 3