Build number partially controlled by repository file contents

[simonness]

Looking for some help implementing the following versioning strategy in VSTS. We'd like to set a build's build number (in the form Major.Minor.Revision) in the following way:

• Control the Major.Minor portion with a commit to a repository (e.g. to package.json or similar)
• Have a revision number that increments from zero taking into account any new Major.Minor portion

@jessehouwing raised the a similar requirement in the comments of pull request #1489.

Our aim is to have a single build that supports this versioning strategy across several long lived branches in a repository.

There are a couple of ways to get close to implementing this:

1. Instead of using a repository file, use a user defined build variable e.g. MajorMinorVersion set at trigger time and then setting the build number format to $(MajorMinorVersion).$(Rev:r). The drawback of this is remembering to set the variable correctly when manually triggering builds on long lived branches.
2. Or... using powershell to read the major minor version from the repository file and then updating the build number from powershell using Write-Host "##vso[build.updatebuildnumber]build number". However we don't have the concept of $(Rev:r) available to us here, so the best we can do is use the unique build id as the revision number. The drawback of this is the revision number does not increment from zero for new Major.Minor versions.

@moswald I've taken a look at the new counter expressions, but not sure the strategy above is yet possible. Any guidance on any other ways to do this would be much appreciated :)

[moswald]

Pinging @ericsciple , who can double-check my work here. 😊

This might be easiest with YAML. You could have your first phase use powershell to read the repository file for your major.minor version. Then, export that value for use in another phase. Your second phase can import that variable, and use a counter expression with that variable as the variable name.

[simonness]

Ah thanks @moswald that makes sense, I think using two phases was the bit I was missing. Out of interest is this possible without YAML? Is it possible to define a variable that uses a counter expression at phase level in the UI?

[TingluoHuang]

We have created a new repository for all YAML related issues, please move the current issue to there.
https://github.com/Microsoft/azure-pipelines-yaml

[bryanmacfarlane]

closing since answered. if anything left to answer, see the point above about moving to azure-pipelines-yaml

[ahaleiii]

Is this a YAML issue because the UI will never support this scenario? The original question did not mention YAML at all, it was only brought up as a possible solution. @simonness followup question also should be an indication that this is not a YAML only issue:

Out of interest is this possible without YAML? Is it possible to define a variable that uses a counter expression at phase level in the UI?

I am also interested in a non-YAML solution. As it currently stands, YAML does not support enough of the features we currently use, so we have decided to not start using it yet.

Based on this response and #1547, it looks like there is no existing way in the UI to do this... the counter must be in the variables, and variables are evaluated at the start of the build. UI does not support output of task to be input of counter.

[moswald]

This is correct. Designer build variables are evaluated at the start of the build, while YAML variables can be evaluated at the start of the phase.

[simonness]

+1 @ahaleiii. I'd like to be able to set a build's build number in the way described without using yaml. If this is only possible with a counter expression at phase level, I'd like to raise a feature request to make it possible to define these using the UI.

[moswald]

Please create a thread here on the Developer Community forums. We use the popularity ranking there to help drive future work.