I have a setup where anyone can create artifacts from any branch of our code base from a pipeline in pipelines -> pipelines then use that artifact to create a release in pipelines -> releases. I want to enable the user to be able to set a variable in the build pipeline that creates the artifact and have that automatically trigger a release once the build finishes. Is this possible and how would I do it?
Thanks for any help.
We cannot set the variable in the build pipeline to create the artifacts and automatically trigger a release once the build finishes
As a workaround, We can configure the Release triggers to automatically trigger the release after the build is complete.
Steps:
Create a new release pipeline->select the build as source type->enable the feature
Continuous deployment trigger and configure it.
Related
I have an Azure DevOps classic release pipeline
There are 2 artifacts (type build) with continuous deployment trigger enabled, and 2 stages
Each stage has an "after release" trigger with an artifact filter, to the respective build artifact.
The builds are for different repos.
However, both stage are being triggered when every build artifact is created, even when I manually create a release...
Expected behavior is:
Build A completes, only stage A is triggered
Build B completes, only stage B is triggered
When I manually create a release, I would like to choose which stage will be triggered. If this is not possible, the trigger both stages
Is this a bug or am I missing something?
Azure DevOps Classic Release - Artifact Filter always triggering release
For this issue ,I am afraid that it is currently not supported in azure devops. If you want different artifacts to trigger the deployment of different rows of stages respectively, it is better to create two pipelines, set the artifact in each pipeline to trigger the deployment on the required stages.
And you could check this topic on developer community
Sorry I should have clarified a bit more. I don't think that triggers will solve all use cases, but having triggers on stages would at least allow you to have the following:
Stage A has trigger /src/appA
Stage B has trigger /src/appB
If you commited (script, code, etc.) to /src/appB, it should use previous artifacts and only build appB and further if requested.
If you think that two artifacts only trigger a part of the pipeline is necessary, you could submit a feature request in our Develop Community site. Our PM and product team will kindly review your suggestion.
I need to know if it is possible to trigger a yaml release pipeline from a Classic Release pipeline.(the one created from the Releases tab under pipelines)
The answer is Yes. You can use the Trigger Build Task extension and queue the YAML pipeline from the release:
Or use Trigger Azure DevOps Pipeline extension.
I have a solution where I want to implement the whole CI/CD circuit, Its a simple Web API in dotnet core 3.1
When it finished, my pipeline build triggers the release deployment, but somehow it stays idle until I manually select "deploy", and I want that step to do it on automatic, if the build passes the checks on the pipeline then, it should trigger an automatic release to my environment.
Nevermind guys, I'm dumb the release trigger needs to be set here:
and I didnt do it.
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.