I’ve noticed that some commit messages (containing Jira issue numbers) are missing from Octopus build information. We use the BuildInformation task in Azure DevOps Server to generate and push the information, and it seems that only the top 50 commit messages are included.
I have tested this locally, and it seems that getBuildChanges method from azure-devops-node-api/BuildApi returns only top 50 by default (some of our builds have a lot more than that). This may be an undocumented default of the underlying Azure DevOps API, however it would be good if the BuildInformation task would get all changes, perhaps through the use of top parameter to increase the number of changes returned?
In my test, I explicitly specified the top: 1000 parameter, and verified that all expected changes are returned. There should be a better way, by using continuation tokens, but I haven’t found a way to get a token from the library methods.
Thank you for the report and the really good suggestion. I’m glad that you have a workaround for this.
Generally, with suggestions like this, we would usually direct you to https://octopusdeploy.uservoice.com/ to see if you can get some traction behind the suggestion.
As this can be framed as a bug, I will aim to repro this on my end and then raise a bug report internally. I’ll also be able to see if I can get the continuation tokens working. At this point, as there is a workaround and it’s a fairly limited use case, I wouldn’t see a high priority put against the bug, so it may be a little while until it gets worked on.
I have the repro and the workaround in a small test app - I don’t have a workaround for the BuildInformation task itself. Are you suggesting I should replace the official integration with my own branch of OctoTFS, with the workaround applied?
For background, our Jira integration relies on Octopus to move the tickets associated with the release, and in this case they are not moved, as Octopus is not aware of the tickets. There is a fairly high chance of this happening, as well - we use a dedicated release branch, and a weekly merge from master (where development is happening) to release can result in a lot of commits brought into release.
Are you suggesting I should replace the official integration with my own branch of OctoTFS, with the workaround applied?
No, not at all. I misunderstood the detail from the first post. I thought you had managed to replace the Azure-devops call within the Octopus Step itself.
Hi Dane,
Thank you very much for looking at this! I see the issue has already been resolved as well
Hopefully it will be released soon and available for update.