Reference different build pipeline for comparison #1293
-
|
We use separate pipelines to deploy to different stages (development, quality, and production). Ideally I would like to generate release notes when I deploy to the quality stage based on the diff to the latest successful deployment on production. However, using the task parameter "overrideBuildReleaseId" I can only reference builds form the same pipeline. Is there any workaround that could fulfill my requirements? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
|
It is not possible to reference different pipelines. This is because the Microsoft API call used to get the associated items requires two IDs for runs of a single definition. For a scenario such as yours, I would get each pipeline to build its own release notes (to a WIKI or as a file pipeline artifact) and then your final pipeline should consume these like any other resource |
Beta Was this translation helpful? Give feedback.
-
|
Thank you @rfennell for getting back to me so quickly. I really appreciate your time! Given the restrictions of the MS API I currently consider the following solution: The current multistage production deplyoment Pipeline has four stages: (1) database test, (2) database deployment, (3) backend test, and (4) backend deployment. Instead of setting up another auxiliary pipeline I could include a fith stage "generate release notes" as part of the production deployment pipeline. If I want to generate release notes before deployment, I can chose to only run the release note generation stage of this pipeline. In order to get consistent release notes corresponding to the acutal deployed state I can use the the paramater "OverrideStageName" to check for the last successful deployment of (4), i.e., the backend deployment. |
Beta Was this translation helpful? Give feedback.
-
|
Yes that is certainly a solution I have used in the past |
Beta Was this translation helpful? Give feedback.
It is not possible to reference different pipelines. This is because the Microsoft API call used to get the associated items requires two IDs for runs of a single definition.
For a scenario such as yours, I would get each pipeline to build its own release notes (to a WIKI or as a file pipeline artifact) and then your final pipeline should consume these like any other resource