I have a VSTS release definition that I want to use for publishing nuget packages for multiple artifacts. The artifacts for the different nuget packages are supplied to the release definition from different build definitions. Only artifacts from the build that triggered the release shall be downloaded and published. The pipeline is setup according to the picture below.
That is, when a build triggers a new release, only artifacts from that build should be published in the release. All artifacts from the other build definitions should be ignored since the version number on those nuget packages are not updated and will fail to push.
Can this be accomplished?
Take a look at this link https://learn.microsoft.com/en-us/vsts/release-notes/2018/mar-05-vsts#improve-release-times-by-partially-downloading-artifacts
And then on that same link see Deploy selectively based on the artifact triggering a release
It will basically explain VSTS new features. The first one is to specify what you want to download on a release phase. The second one is to add a custom condition on a phase to define if it should be executed.
So you could create two phases, one for each of your artifacts. Each phase would only download the corresponding artifact and only run if the custom conditional evaluates true, using the new release variable Release.TriggeringArtifact.Alias.
Note that this release variable is only present if the release is continuous deployment.
Related
We're using on-prem AzureDevopsServer2019, with on-prem build agents. I'm trying to create a new release, which consists of 3 artifacts.
The (retained) build artifact I want doesn't show in the available builds comboboxes of the new release (this has happened on more than one artifact)
Alternatively, when I try and create a release directly from the retained build, I scroll through my many historic builds, find the "missing" build, click release, populate the other artifacts in the new release, then when I click "Create" get:
"VS402962: No artifact version ID is specified corresponding to
artifact source 'MyBuild'. Specify a valid value and try again
Any idea what's up?
Build artifact missing from new release's combo, creating release directly from retained build causes VS402962
You should check if you specify the projectname for the alias, it should be the source alias. Since you want to use the build artifacts, the “alias” variable should be your build definition name not your project name.
If above not work for you, try to create a new build pipeline, there is a ticket report this issue, but there is no one effective solution. This is an annoying issue in Azure DevOps:
Unable to release ~20% of the pipeline builds to any release pipeline
If you encounter this too, please reopen it and add your feedback and more useful information.
Last week, our team decided to move all separate .NET projects into a single solution. Because we were already using Azure DevOps with separate build pipelines for each project, we looked into the possibility to only trigger builds whenever there are changes to a specific project. This, to prevent the build agents from rebuilding the entire solution on every commit.
Because our source repository is a locally hosted Git one, we do not have the niceties of using path filters, so we resorted to using a Powershell task to determine if all upcoming tasks should be skipped, using a custom condition (explained in this SO question).
Now, on every commit, all builds are triggered, but the builds resolve for themselves if they should continue to build and (more importantly) if they should publish a build artifact at the end. An example of such a skipped build is below:
However, every time such a build 'succeeds', a new artifact is created, even though the publish artifact task is skipped. The problem is that all our release pipelines are triggered when a build pipeline creates an artifact. So every time a build is skipped like shown above, the release pipeline triggers and tries to deploy the artifact. But it fails, because the artifact it uses to deploy does not really exist (it seems like it is empty, and the build pipeline actually doesn't mention an artifact on the Summary tab), so any operations on the artifact fail in the release pipeline.
Our release pipelines are set to trigger on source type build artifact, for the corresponding build pipeline, with the default version parameter set to latest.
How is it possible that, even though the publish artifact task is skipped, the release pipeline still triggers and tries to deploy an empty artifact?
I assuming you enable the Continues Delivery in the Releases pipelines, this option is not related to build artifacts. this option means that Release will be triggered when the build succeeded (not matter if he has artifacts or no).
So this is the reason why after each build a new release started.
As workaround, you can add a task in the build that add "build tag" only when there is a artifacts, and in the release artifacts options, instead of choose Latest you can choose Latest from the build pipeline default branch with tags and specify the tag you put in the build.
Another option is in the "Stages" click on the triggers and then it's configured to "After release" so enable the "Artifact filters" and specify there the build tag.
How do you add a build tag? add a PowerShell task with this command:
Write-Host "##vso[build.addbuildtag]test-tag"
I currently have a release defined for pushing clients to an internal nuget server.
Each release is identical in terms of steps, the only thing that changes is the triggering artifact.
However when I add another artifact to a "generic" release, so that there are now ClientA and ClientB artifacts on the release, both artifacts are downloaded when the release is triggered and they are both then pushed.
What I would like to know is if it is possible to have the release only download the triggering artifact.
Example:
A release is triggered on both ClientA and ClientB.
ClientB is released. The build triggers and only uses the ClientB artifact during the deployment.
I don't think this is possible at the moment, but something similar is possible though.
Create a task group from the current release definition as described here: https://learn.microsoft.com/en-us/vsts/pipelines/library/task-groups?view=vsts
There clone the release definition and change the artifact from ClientA to ClientB.
You'll end up having two release definition, both sharing the steps but the artifacts will be different.
EDIT: PowerShell script to download Build artifacts
Eddie suggested a nice workaround. Here's how you can pull down an artifact manually.
You need to enable Allow scripts to access OAuth token
Add a PowerShell task to each phase and reference the DownloadBuildArtifacts.ps1 script
If the release is triggered by build artifacts, the value of the pre-defined variable "$(RELEASE.TRIGGERINGARTIFACT.ALIAS)" will be the triggered artifacts alias. You can get the value of this variable to determine which artifact trigger the release.
There isn't any way to achieve this out of box. But you can disable auto download artifacts and add a powershell script in your release definition to get the triggered artifact and download it.
There isn't the way to just download the triggered artifacts, but you can identify which artifact trigger this release through RELEASE_TRIGGERINGARTIFACT_ALIAS variable.
So, you can push corresponding one per to that variable.
I have successfully created a Build definition in VSTS for some SharePoint client side projects that I'm working on. I tried creating a Release definition but I can't seem to find any way for me to copy/download the artifacts created from my build definition locally. I may be missing something since I'm still quite new with VSTS but I can't seem to figure it out.
To downbload build artifacts from release when build successful, you can specify the release definition as below:
Add the build artifacts with latest version in release definition.
Enable Continuous deployment trigger for the artifacts.
Select the private agent which you want to download on the local machine.
Now when a build succeed, a new release will be triggered to download the latest build artifacts.
I have two build definitions in Visual Studio team Services.
I also have two release definitions in Visual Studio Team Services.
I want the release to be automatically triggered according to which build completes, but on the release definition.
When I go to the triggers tab, on the release definition, and select the continuous deployment option, it only gives me one artifact source label, for both builds.
How do I get my builds to produce different names artifact sources, so the releases can be triggered according to which build is run?
OK, easy answer found
On the release definition, click on "Artifacts", then link to the second build definition, and then you can trigger the release from the second build.