checkStage with tag between pipelines

[danielbanks]

I'm trying to understand if I can get the changes between successful runs of different pipelines. Same repo but different pipelines.

The case I have is a release pipeline and a hotfix pipeline, both are tagged with release. It works fine between successive runs of the same pipeline but hotfix doesn't seem to recognise the release tag on the release pipeline and instead pulls the whole history in since the first available run.

Is this possible?

Config:

- task: XplatGenerateReleaseNotes@3
         displayName: 'Generate Release Notes'
         inputs:
         outputfile: '$(versionName).md'
         templateLocation: 'InLine'
         inlinetemplate: |
           ## Customer App Release Notes

           **Release Number** : {{releaseDetails.name}}
           **Release completed** : {{releaseDetails.modifiedOn}}
           **Build Number**: {{buildDetails.id}}

           ### Change Log
           {{#forEach pullRequests}}
           * **[{{this.pullRequestId}}]({{replace (replace this.url "_apis/git/repositories" "_git") "pullRequests" "pullRequest"}})** {{this.title}}
           {{/forEach}}
         CheckStage: true
         dumpPayloadToConsole: false
         dumpPayloadToFile: false
         replaceFile: True
         getParentsAndChildren: False
         getAllParents: False
         tags: 'release'
         getIndirectPullRequests: False
         stopOnError: False
         considerPartiallySuccessfulReleases: False
         checkForManuallyLinkedWI: False
         wiqlFromTarget: 'WorkItems'`

[rfennell]

The simple answer is you can't compare two different pipelines.

The task relies on calls to the Azure DevOps REST API and shows the differences between runs of the same pipeline definition. To deliver what you are asking for would be a complete rewrite.

To turn the question around, why do you have different pipelines for Hotfix and Release?

Could you not have a single pipeline and use conditional insertion logic to enable or disable stages that should be bypassed for one or other release type.

This is the technique I try to use as it means only one YAML pipeline to maintain, and ensures all my means of release pass through the same gates.

[danielbanks]

Personally I prefer to keep things simple with a pipeline doing one thing rather than lots of logic and configuration. It helps reduce maintenance costs and cognitive load. However I appreciate that's a different philosophy and that means we can't use this lovely tool.

Thanks for taking the time to respond.

[htekdev]

@rfennell to add to this point. I had issues with needing to have the tags be "get builds that contain a subset". Since there are multiple tags that mean different things I wanted a partial match.

I created a PR #1318 for this. Just need a review.

[progrock100]

@rfennell does this apply between branches as well ?
I have a pipeline, so it's one pipeline, but I have 2 slightly different yamls at the moment for 2 different branches, develop and blah.
develop does not have the "generate release notes" task currently, as well as some other changes.

I will merge blah into develop... when needed, and when I do that the yamls will be the same, but will the release note task work correctly ?
I will probably then maintain one yaml and use the conditional insertion logic to only run the release notes for develop or whatever branch we will release from.

[rfennell]

Yes, conditional logic is the best option