Open booyaa opened 2 years ago
Noticed that #4 has changed how deploymentSequenceNumber
is computed. So I'm retesting just in case this resolves the issue.
I think this usually happens when there's no JIRA like issues listed under the changes section - which might be related to how branches are cut for release so changes aren't detected by Azure DevOps
I'd be nice to know what the Azure DevOps GUI says under changes
Here you go, I guess that explain our problem. I think my colleague grabbed the merge commit hence all the other commits with the Jira ticket info is missing. I'm going to do more testing to see if I can reproduce in my test pipeline. Previously all I've done created a release branch off main, which is probably why it worked for me, but not in our app pipeline.
I'm probably going to repurpose/replace the private function Get-AzureDevOpsBuildChanges
to do output something like this git log --pretty=oneline --abbrev-commit main...releases/a.b.c
ugly, but it would get us the vital Jira ticket info that vanishes in the related changes view for the pipeline run.
We've been running a fork (to enable debugging), I'll let you know our progress. Not ideal, but gets our team out of a tight spot at the moment.
From what I've been reading (the DevOps REST API is a nightmare to navigate) endpoint to list changes doesn't handle GitHub repos correctly. The other alternative is to look at the change history in the Environments.
@mwheeler-ep just thought I'd through this one out there, what branch strategy do you use at EducationPerfect? We merge the feature branch into "main" (which deploys to dev) and then we cut a "release" branch off main (which deploys to staging and prod environments).
I think the first version I wrote of this did a git log ...
. It's not a bad idea :)
For some of our repos we also cut release branches and I think run into the same issue.
I've written the code, it's a bit of a hack 😢 we're going to test in our environment, if it proves successful I'd be happy to create a PR if it might be useful to others.
I've also run into this issue - with the master code as of this week, the path $build_changes = $response.fps.dataProviders.data.'ms.vss-traceability-web.traceability-run-changes-data-provider'.artifactsData.data did not match to a real path in the devops '_tracability' url. So I modified that to use the 'artifact id' data in my fork and that seems to work when the branch being built has a jira id in it, but does not work when PRing from a feature branch to a develop branch or release branch. Are there any other areas in the devops data that we can pull more reliable jira IDs?
I've also hit this issue. Any good solutions discovered?
Output from DevOps
Steps to reproduce
This is primarily to help others who need to access the internal (private) functions in this excellent plugin.
Usage
https://dev.azure.com/<Organization Name>/
Useful docs
Notes
I'm going to see if I can test the PowerShell scripts locally using the build values from a previous pipeline run. Any pointers would be appreciated.