I have a task which I would like to run after the completion of any of my release pipelines. The release pipelines need to complete their run and finish completely. Then this final pipeline should run and be passed the artefact from the build and release pipeline.
Is there a way to run a task or pipeline after a release pipeline has completed?
I need to run this task after the release pipeline has completed because the task I've written needs to request information from the DevOps REST API which will not return anything until the release pipeline has finished.
There is an extension in the Marketplace called "Trigger Build Task" (https://marketplace.visualstudio.com/items?itemName=benjhuser.tfs-extensions-build-tasks) that enables the chaining builds.
It allows your Release pipeline to complete and a separate Build pipeline is started on a different thread/process, so you should be able to query the information you need from that triggered Build.
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.
To set the stage, I have two pipelines created in yaml, call them Build-CI and Release-CD. Release-CD has a pipeline resource dependency on Build-CI so when Build-CI completes, Release-CD is triggered.
The problem I am having is specific to build artifacts. In order to make my Release-CD jobs more efficient I am only downloading the build artifact that is necessary to complete the job, rather than having all jobs download all artifacts. I do this using the following syntax
- download: triggeredBy
artifact: 'drop'
patterns: '**/ArtifactSubFolder/*'
In this case "triggeredBy" is the name of the pipeline resource.
My understanding is this will download the artifacts from the build that triggered the release. And this works when the build and release occur back-to-back. However, the Release-CD pipeline contains multiple stages (dev, test, stage, prod). And as much is the case, the release will go to "test" and sit there waiting approval for a day or so before being promoted to "stage".
When this delay occurs and we approve the release to the next environment we get errors saying that the build artifacts are not found, and the build id it refers to is not the build id of the triggering build, but rather the build id of a build that occurred between the deploy to "test" and the approval to "stage"
How do I ensure that when approving these release pipelines to subsequent stages that they are indeed downloading artifacts from the original triggering branch?
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.
I have two pipelines on azure devops that do the following:
BUILD PIPELINE
Asks the user for the desire branch name and ticket id (from our ticketing system). Using two "settable at queue time" variables.
Gets the files from the specified branch name, builds the project and generate the artifacts that are later use by the RELEASE pipeline
RELEASE PIPELINE
This release pipeline is being triggered by the completion of the BUILD pipeline specified before. This pipeline completes the following tasks:
Creates new app service slot using an Azure CLI command task. In this task I need the ticket id, in order to create the slot with the corresponding ticket id as its name
Deploy the application to the created app service slot
I haven't found a way to pass to the RELEASE pipeline the ticket id the user entered when running the BUILD pipeline that triggered this RELEASE.
Unfortunately, there's no such a build-in function in Azure DevOps. While thanks to Martin Hinshelwood, we had an extension- Variable Tools for Azure DevOps Services to achieve the goal.
As you can see in the extension's doc, add a Variable Save Task in your build pipeline and a Variable Load Task in your release pipeline. After these two tasks, the variables are fully passed to your release.
Check below as reference:
I have an Azure DevOps CI Build and Release pipeline in following setup:
CI Build runs with each new commit in develop branch and creates a Build Drop (Artifact)
Release pipeline runs with each new Artifact and deploys to INT and eventually to PROD (after manual approval)
I would like to add a 3rd stage (called eg. MONITOR) which would run after the PROD release every night using the same drop as the PROD stage used, with following schema:
[Build Drop] -> [INT] -> manual approval: [PROD] -> nightly scheduler: [MONITOR]
This seems to be impossible to me, do you know how to achieve this goal?
Following is crucial for me:
the MONITOR and PROD run always from exactly the same Artifact
MONITOR is executed only if the PROD was successful
if there is a newer PROD release, the old MONITOR is not executed any more and instead the newest one is executed using the newest Artifact which made it to PROD
I tried so far following:
merge develop to master when the commit made it to PROD. And then used scheduled nightly Build from master with MONITOR stage - it works, but MONITOR uses different Artifact than PROD, so not usable for me
used scheduled trigger for MONITOR after PROD - does not work, the MONITOR is executed only once at scheduled time and never again
created extra release pipeline based on specific Artifact version with a scheduled trigger - this works, but I have to maintain the specific Artifact version manually with each successful PROD release. Another caveat is that I have to use 2 separate pipelines which makes the overview not so nice. (but, so far the best solution I achieved)
do you have better ideas? many thanks
What I would do is have 2 separate Release Pipelines.
This allows you to schedule the release without producing a new artifact (scheduled build).
Then, I would do some of what #Soccerjoshj07 suggested in that I would invoke the REST api in a task on the MONITOR pipeline/stage.
I would make the REST api call to the Releases endpoint to get the top=1 releases for releasedefinitionid=x. Then use the Release Environment endpoint to get the PROD environment for that latest release id. With the environment in hand, check the status for succeeded. If not, fail the release.
Edit as per new requirement outlined in comment
Given PROD.1 is succeeded and PROD.2 is failed when MONITOR is triggered, then the artifact from PROD.1 should be used for MONITOR.
With this criteria I would change some things. Rather than have the MONITOR go digging for the latest PROD release and fail if the latest is failed, I would make the successful PROD stage tag its build artifact and employ artifact filters on the Monitor pipeline.
The tagging can occur via the REST api or using the Tag Build or Release Task from Colin's ALM Corner Build & Release Tools and might look like this:
Are you using a YAML template, and if so have you played with the cron schedules? https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#scheduled-triggers
If using classic Release UI, I think you can have the definition trigger be on a schedule but that would queue the entire definition. You might have to get creative with variables and maybe create 'isScheduled=true' and use that to determine if it should skip tasks.
Other ideas:
Create a logic app or function app that calls the REST API? Sample app and github link here: https://oshamrai.wordpress.com/2019/04/22/azure-devops-rest-api-19-queue-builds-and-download-build-results/
The Azure-Devops AZ CLI extension might be easier, though: https://learn.microsoft.com/en-us/cli/azure/ext/azure-devops/pipelines/build?view=azure-cli-latest#ext-azure-devops-az-pipelines-build-queue
Beside setting up two release pipelines, if you want to use scheduled trigger for only one Stage, I am afraid there is no such out of box way to achieve that, scheduled trigger is only for entire pipeline.
As a workaround, you can add a custom condition for the job of MONITOR stage.
For example in yaml:
- stage: MONITOR
jobs:
- job:
condition: and(always(), eq(variables['Release.Reason'], 'Schedule'))
steps:
In UI , you can set this in Run this job of agent job:
In this case, the stage only executed when the release triggered by scheduled trigger. If the release is triggered by other reasons, the MONITOR stage will be skipped .
The limitation of this workaround is that when your pipeline is triggered by a scheduled trigger, two other stages are also executed.
Or write a script with powershell task (in INT/PROD stages) to determine whether Release.Reason is Schedule. If yes , skip the current stage.
For how to obtain the latest artifact version of PROD and determine the deployment status of PROD, you can refer to the two answers above.