0

I've created a powershell script that updates a Pipeline Variable during a Release Pipeline. It takes the custom variable and updates it with a new version using semantic versioning with every run.

I've tried to add this custom variable as the Release Pipeline but keeps on giving me an error "Names of releases from this pipeline will not be unique. Use pre-defined variables to generate unique release names."

I've tried setting the variable to "Settable at Release" and putting the scope to "Release"

Does anybody perhaps know if there is a way to let the release pipeline know this is a dynamic variable that changes?

The only other option is to add the revision number to it $(versionnumber)$(rev:.r)

false
  • 10,264
  • 13
  • 101
  • 209
Trevor
  • 15
  • 7
  • It might change, but it's **not** guaranteed to be unique. Release names need to be unique. Thus, you can't do what you want. – Daniel Mann Oct 08 '19 at 13:39
  • Totally agree. Hoping there is a way that will tell the release pipeline it's a unique value each time. – Trevor Oct 08 '19 at 13:57
  • There is. You mentioned it in your question. `$(rev:.r)` And you missed my point. What if you run the release twice, and it uses the same version number because a step fails before the pipeline is updated, or the pipeline itself fails while updating its own version number? Next time you run the pipeline, you'll get the same version number. Your scheme **is not guaranteed to be unique**. You need to add something that **is** guaranteed to make the name unique. – Daniel Mann Oct 08 '19 at 14:22
  • Thank you for the feedback Daniel. I totally understand what you are saying and yes, I've thought about the exact scenario you mentioned on a release failing before the step as well and understand that this is one of the reasons why Azure probably (or likely) does this. Thank you again for your time and input. Much appreciated. – Trevor Oct 09 '19 at 17:58

1 Answers1

2

use Custom Pipeline Variable for Release Name

For this issue ,I think it not feasible to achieve it. Release name must be a unique name, the $(rev:r) token can ensure that every completed build/release has a unique name because it's adding a incremental number for each release. When a build/release is completed, if nothing else in the number has changed, the Rev integer value is incremented by one. So, basically we cannot achieve that without using $(rev:r), unless you can defined a token which has the same function with $(rev:r).

In addition,you can also use $(Build.BuildNumber) or $(Release.ReleaseId) which are also unique.

For the similar issue,please refer to this case .

Hugh Lin
  • 17,829
  • 2
  • 21
  • 25
  • Thank you Hugh. Yes .. the $(rev:r) was the only solution. We are currently using the ReleaseID but due to it all being in one project and we have about 10 pipelines the versioning would jump about 30 versions per day. And we're also using multilple builds artifacts so the build numbers are unfortunately not an option for us since each build has it's own version already different from another. However, I've thought about it and think I can find a way to use the $(rev:r) in the versioning I want to use. Thank you for your time and input. Much appreciated. – Trevor Oct 09 '19 at 18:02
  • @Trevor Glad to help you :) If this answer is helpful to you , you could [Accept it as an Answer](https://meta.stackexchange.com/questions/5234/how-does-accepting-an-answer-work). This can be beneficial to other community members reading this thread and we could archive this thread, thanks. – Hugh Lin Oct 10 '19 at 11:24