0

I have a release pipeline that is triggered whenever a new version of a Universal Package is published. Now, as my package can be promoted to a specific view (defaults are @local, @prereleas or @release), I'd like to use the selected view in a custom condition for the subsequent steps in my pipeline.

Something like :

eq($(hopefullysomepredefinedvar), '@prerelease')

However, I checked the available pre-defined variables and the 'view' information doesn't seem to be available unless I missed something.

An even cleaner solution would probably be to use separate stages in the release pipeline and evaluate the 'view' through some pre-deployment condition, but I didn't find a way to do that.

Finally, I tried to add the same artifact (Universal Package) multiple times, with different 'views' to 'filter' on. So once with view @prerelease and once with view @release. However, it seems like my pipeline does not get triggered at all with this configuration.

Is there a solution (or a good workaround) for this?

Thanks!

Jonas
  • 88
  • 1
  • 6

1 Answers1

2

As a workaround, you can write a script through rest api to judge the package view. If there is a view named Prerelease, set the condition variable to true.

GET https://feeds.dev.azure.com/{organization}/{project}/_apis/packaging/Feeds/{feedId}/Packages/{packageId}/versions/{packageVersionId}?api-version=6.0-preview.1

Sample script:

$url = 'GET https://feeds.dev.azure.com/{organization}/{project}/_apis/packaging/Feeds/{feedId}/Packages/{packageId}/versions/{packageVersionId}?api-version=6.0-preview.1';
$token = "PAT"
$token = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($token)"))   

$response = Invoke-RestMethod -Uri $url -Headers @{Authorization = "Basic $token"} -Method Get -ContentType application/json 

$results = $response.views.name
       
foreach($view in $response.views){
    
        if($view.name -eq "Prerelease"){   
            $condition = "true"          
       }
}

Write-Host "results = $($results | ConvertTo-Json -Depth 100)"
Write-Host "result = $condition"

Then you can set custom condition like this eq($(condition), true).

The second workaround:

Add multiple artifact source and then we specify the Source alias like below:

enter image description here

We can use the Release.TriggeringArtifact.Alias default variable to get the alias of the artifact which triggered the release in the condition to judge the view.

For example: condition: contains(variables['Release.TriggeringArtifact.Alias'], '@prerelease' ))

Hugh Lin
  • 17,829
  • 2
  • 21
  • 25
  • Afaik the API assumes I know the version number, right? In the release pipeline artifact that triggers the pipeline I just specify 'Latest' and I seem to remember having read somewhere that the API doesn't support that. – Jonas Jan 21 '21 at 09:00
  • 1
    `I just specify 'Latest'` You can try this [api](https://learn.microsoft.com/en-us/rest/api/azure/devops/artifacts/artifact%20%20details/get%20package?view=azure-devops-rest-6.0). [The default](https://i.stack.imgur.com/a9cyG.png) is the latest version. – Hugh Lin Jan 21 '21 at 09:10
  • ok, I'll give that a try. I just figured that I also have the version that triggered the pipeline from the triggering artifacts variables, e.g. [BUILD_BUILDID] --> [0.5.0] so I could even pass that onto the API. – Jonas Jan 21 '21 at 09:18
  • The API call works fine. The only problem with this approach is that if I remove the view 'filter' from the artifact trigger, the pipeline only gets triggered when a new version of the package is published and not when the version is promoted to a specific view. – Jonas Jan 21 '21 at 18:22
  • If you want the pipeline to be triggered when the version is promoted to a specific view, why do you remove view 'filter' from the artifact trigger? In addition, I added another workaround in the answer, please view it. – Hugh Lin Jan 22 '21 at 09:59