I have a requirement to get the build artifact name in release? I dont see a predefined release variables which can get this. Is there a way to fetch this?
If you mean you want to get the Artifact Name which is defined in Publish Build Artifacts task in Build process (By default it's Drop), then you can run below PowerShell script calling the REST API to retrieve the value and set a variable with logging command. After that you can use the variable in subsequent tasks...
Enable Allow scripts to access the OAuth token in Agent Phase
Add a PowerShell task to run below script
$url = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECTID/_apis/build/builds/$env:BUILD_BUILDID/artifacts?api-version=4.1"
Write-Host "URL: $url"
$pipeline = Invoke-RestMethod -Uri $url -Headers #{
Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
Write-Host "artifactName:" ($artifactName = $Pipeline.value.name)
#Set Variable $artifactName
Write-Host "##vso[task.setvariable variable=artifactName]$artifactName"
#Then you can use the variable $artifactName in the subsequent tasks...
This is kind of a hack/kludge, but if you name your Release to be the same as the package you are releasing, you can get the name from the variable
$(Release.DefinitionName)
So if your build creates a package called My.Cool.Package in a build pipeline called my_cool_package, that ends up being aliased in the release pipeline as _my_cool_package.
Naming the Release pipeline the same as the package (My.Cool.Package) allows you to access the package and files within it (for doing XML and JSON transforms for example in other tasks) by using
$(System.DefaultWorkingDirectory)/$(Release.PrimaryArtifactSourceAlias)/$(Release.DefinitionName)
This is well-documented under the sections General Artifact Variables and Primary Artifact Variables.
The primary artifact name is Build.DefinitionName.
Related
I have an Azure release pipeline that I am using for a Windows Virtual Desktop deployment.
I have created a simple Powershell task to obtain some information about the existing session hosts available and capture it to a list which I have then set to a dynamic variable using
$sessions = "vm_name1 vm_name2 vm_name3"
write-host "##vso[task.setvariable variable=sessions;isOutput=true;]$sessions"
I can then retrieve this fine in later tasks by using
write-host $(taskreference.sessions)
result: vm_name1 vm_name2 vm_name3
However, I need to access be able to parse this variable $(sessions) to obtain the individual host names to be used in later steps of my release pipeline.
i.e. $vms = $(sessions).Split(" ")
$vms[0]
$vms[1]
etc etc
I have tried various methods to access and expand this variable but ultimately am struggling to get anything working as it will always return null. When using a Azure CLI task, I am able to successfully access the variable using the exact same code. I suspect this is something to do with how the tasks work during run time/compile time.
Is there any way that I could parse the variable properly to obtain the individual host names?
The one you described would work fine if the variable is passed in as a string parameter.
Else this might work.
$vms = "$(sessions)".Split(" ")
$vms[0]
$vms[1]
We are using azure devops for our CI/CD process. Many a times, in order to do some custom builds, we need to download the specific maven jar from artifact repo.
Is there a way (commandline or API) to do the same ?
Again the question is about download specific jar from azure artifacts.
Azure Artifacts - Download a specific version of maven artifact
The answer is yes. We could use the REST API Maven - Download Package to download the specific jar from azure artifacts:
GET https://pkgs.dev.azure.com/{organization}/{project}/_apis/packaging/feeds/{feedId}/maven/{groupId}/{artifactId}/{version}/{fileName}/content?api-version=5.1-preview.1
First, we need to get the feedId. We could use the REST API Feed Management - Get Feeds to get the feedId:
GET https://feeds.dev.azure.com/{organization}/{project}/_apis/packaging/feeds?api-version=5.1-preview.1
Note: The project parameter must be supplied if the feed was created in a project. If the feed is not associated with any project, omit the project parameter from the request.
For other parameters in the URL, we could get it from the overview of the package. Select the package and open the package, we could get following view:
Now, we have all the parameters, feedId, groupId, artifactId, version, fileName.
So, we could use the REST API with -OutFile $(Build.SourcesDirectory)\myFirstApp-1.0-20190818.032400-1.jar to download the package (Inline powershell task):
$url = "https://pkgs.dev.azure.com/<OrganizationName>/_apis/packaging/feeds/83cd6431-16cc-480d-bb4d-a213e17b3a2b/maven/MyGroup/myFirstApp/1.0-SNAPSHOT/myFirstApp-1.0-20190818.032400-1.jar/content?api-version=5.1-preview.1"
$buildPipeline= Invoke-RestMethod -Uri $url -OutFile $(Build.SourcesDirectory)\myFirstApp-1.0-20190818.032400-1.jar -Headers #{
Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
} -Method Get
Since my maven feed is an organization scoped feed, I omit the project parameter from the URL.
The result:
I've found this way:
Open feed page in Azure, click Connect to feed
Choose Maven, copy the URL from Project setup > repository/url of the pom.xml sample.
That should look like:
https://pkgs.dev.azure.com/YOUR-ORGANIZATION/_packaging/YOUR-FEED-NAME/maven/v1
Append the artifact info to that link:
https://pkgs.dev.azure.com/YOUR-ORGANIZATION/_packaging/YOUR-FEED-NAME/maven/v1/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar
Hint: compare it to the one from maven repository:
https://repo1.maven.org/maven2/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar
I am trying to setup azure pipelines to trigger a build on every PR update, and a release on every merge. For a couple of reasons when the PR is merged, i need to access data saved by the latest validation build of the PR.
However to do that i need the PRid during the run of the Release pipeline. How can one achieve that?
From the release you can retrieve the commit Id which triggered the build.
Then you search for the commitId in the list of completed PRs and retrieve your PR number.
$commitId = "$(RELEASE.ARTIFACTS.{YOURARTIFACTALIAS}.SOURCEVERSION)"
$repoId = "$(RELEASE.ARTIFACTS.{YOURARTIFACTALIAS}.REPOSITORY.ID)"
$pullRequestsUri = "https://dev.azure.com/{organization}/{project}_apis/git/repositories/" + $repoId + "/pullrequests?searchCriteria.status=completed&api-version=5.1"
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f "", "$(System.AccessToken)")))
$pullRequests = Invoke-RestMethod -Uri $pullRequestsUri -Method GET -ContentType "application/json" -Headers #{Authorization = "Basic $base64AuthInfo" }
foreach ($value in $pullRequests.value) {
if ($value.lastMergeCommit.commitId -eq $commitId) {
$pullRequestId = $value.pullRequestId
}
}
Write-Host $pullRequestId
Based on your scenario, to my knowledge, it is complex to get related build information in your release. Besides, it may cause unexpected result if not cover all possible scenarios.
I'd suggest that you could refer to these steps blow:
Remove publish build/pipeline artifact or unnecessary tasks, just remain tasks for validation, which will save a lot of time. (Because, in general, the validation build will be triggered too many times, waste too much time to publish useless artifact or other data)
Create a new build pipeline and enable Continuous integration for target branch (e.g. master)
Add publish build/pipeline artifact task
Edit release pipeline and link this build pipeline and enable Continuous deployment. (Could add additional filters)
With this way, after completing the pull request, this new build pipeline will be triggered and will publish necessary artifact, then the release will be triggered.
For pull request validation builds, they just do tasks to validate the code (e.g. build project), but not publish artifact.
Simple scenario for saving time:
A pull request has 50 validation builds
old way: publish artifact of each takes 1 minutes, then total time is 50 minutes
new way: the new pipeline do tasks for build and publish, it just run once and may just takes 10 minutes.
Then you can save 40 minutes.
In Release Pipeline, you could use the variable $(RELEASE.ARTIFACTS.<<Source alias name>>.PULLREQUEST.ID) to get the Pull Request ID.
Note: the Source alias name is the name set in the release artifacts.
By the way, if you use a default variable in your script, you must first replace the . in the default variable names with _.
For example: $env:RELEASE_ARTIFACTS_<<Source alias name>>_PULLREQUEST_ID
Here is a doc about the Release variables.
Hope this helps.
I have a release pipeline that triggers when there's a PR to master. I want to be able to trigger a release from a build queue (so without creating a pull request).
The proces now is to manually queue a build of a specific branch (this is fine):
Now I have to manually release the branch as well:
I want to automate this proces.
Like I said my current automated release proces is only triggered when there's a PR for master:
Any suggestions how to trigger a release from a custom build action?
If you want to trigger a release from inside the build - you can use Azure Devops rest api for that. This is the rest api call you are interested in:
https://learn.microsoft.com/en-us/rest/api/azure/devops/release/releases/create?view=azure-devops-rest-5.0
you can use something like this to achieve that:
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("${user}:$(PAT_TOKEN)"))
$bearerAuth = #{ Authorization = "Basic $base64AuthInfo" }
Invoke-RestMethod POST https://vsrm.dev.azure.com/{organization}/{project}/_apis/release/releases?api-version=5.0 -Headers $bearerAuth -ContentType "application/json" -Body xxx
I think you can choose to add a source with Build as the artifact in Release, so you can trigger a release from a build queue without creating a pull request.The solution provided by 4c74356b41 is a good method, you can also try it.You can add a powershell task to the agent job of the build pipeline, and then write the script with the above rest api provided by4c74356b41 in the Inline script to run the build.
Hope this helps.
I'm setting up my production environment and would like to secure my environment-related variables.
For the moment, every environment has its own application parameters file, which works well, but I don't want every dev in my team knowing the production connection strings and other sensitive stuffs that could appear in there.
So I'm looking for every possibility available.
I've seen that in Azure DevOps, which I'm using at the moment for my CI/CD, there is some possible variable substitution (xml transformation). Is it usable in a SF project?
I've seen in another project something similar through Octopus.
Are there any other tools that would help me manage my variables by environment safely (and easily)?
Can I do that with my KeyVault eventually?
Any recommendations?
Thanks
EDIT: an example of how I'd like to manage those values; this is a screenshot from octopus :
so something similar to this that separates and injects the values is what I'm looking for.
You can do XML transformation to the ApplicationParameter file to update the values in there before you deploy it.
The other option is use Powershell to update the application and pass the parameters as argument to the script.
The Start-ServiceFabricApplicationUpgrade command accept as parameter a hashtable with the parameters, technically, the builtin task in VSTS\DevOps transform the application parameters in a hashtable, the script would be something like this:
#Get the existing parameters
$app = Get-ServiceFabricApplication -ApplicationName "fabric:/AzureFilesVolumePlugin"
#Create a temp hashtable and populate with existing values
$parameters = #{ }
$app.ApplicationParameters | ForEach-Object { $parameters.Add($_.Name, $_.Value) }
#Replace the desired parameters
$parameters["test"] = "123test" #Here you would replace with your variable, like $env:username
#Upgrade the application
Start-ServiceFabricApplicationUpgrade -ApplicationName "fabric:/AzureFilesVolumePlugin" -ApplicationParameter $parameters -ApplicationTypeVersion "6.4.617.9590" -UnmonitoredAuto
Keep in mind that the existing VSTS Task also has other operations, like copy the package to SF and register the application version in the image store, you will need to replicate it. You can copy the full script from Deploy-FabricApplication.ps1 file in the service fabric project and replace it with your changes. The other approach is get the source for the VSTS Task here and add your changes.
If you are planning to use KeyVault, I would recommend the application access the values direct on KeyVault instead of passing it to SF, this way, you can change the values in KeyVault without redeploying the application. In the deployment, you would only pass the KeyVault credentials\configuration.