Azure DevOps: build information missing work item links?

[Thomas_B]

Hi,

When using the “Push Package Build Information to Octopus” step, my package only includes information about the commits associated with the build, and not the work-items: when I open the package details screen on octopus deploy, there are only commit details.

As a consequence, the release note is empty: there a no work items linked. As stated in the docs, I expected that the work items could be automatically associated.

In the build details in Azure Devops, I can see that multiple work items are associated with the build.

Based on OctoTFS source code it seens the buildinformation.json file generated by the “Push Package Build Information to Octopus” does not generate work item information, only information about commits.

The Publish Release Notes on Create Release step, which is now considered legacy, supports publishing work item information when creating releases.

Is it a known limitation ?

Edit: I can browse the code responsible for grabbing related work items for the build in the Create Release step. This code could be used in the Publish Build Information step to create a workItem propery in buildinformation.json and publish work item information for the build.

For now I will certainly revert to the previous release notes when creating the release instead of the publish build information step.

[paul.calvert]

Hi @Thomas_B,

Thanks for getting in touch!

When using ADO and the new push build information step the Work Items process is handled separately. If you navigate to Configuration > Settings > Azure DevOps Issue Tracker and configure it. Then when you create a release Octopus will retrieve any relevant Work Items for packages assigned to that Release and add them to the release notes.

Full details can be found here: Azure DevOps work item tracking integration - Octopus Deploy

Regards,
Paul

[Thomas_B]

Oh, ok. This choice seems weird to me since it requires that my DevOps server can be accessed from Octopus Deploy, which is not the case here (we are using an on-premise DevOps server).

I will see if I can open our DevOps Server instance…

Also, the code to add work items in the json seems to be easy to add here, I don’t see the value of adding another process to retrieve work item details from the Octopus Server when I can push everything in the json.

Bonus question: Is the buildinformation.json schema documented somewhere ? Does a property exists to manually upload work item details?

Bonus problem: we use Octopus with package from both our on-premise DevOps AND the cloud hosted dev.azure.com. Having a single point of configuration for an external DevOps server is a strong limitation in our case: we will be able to use this feature only for a single server.

[paul.calvert]

One of my colleagues put together a blog post on manually adding build information that does provide additional detail on the buildinformation.json schema available here: Manually push build information to Octopus - Octopus Deploy

[Thomas_B]

Excellent, thank you. But this post states that you cannot add work item details when sending data.

It explains why the build-information step does not add these.

I get that the new issue tracker system allows to configure one issue tracker and octopus will then automatically get issues details when creating a release, and there are certainly cases when it’s a better solution.

I also get that you still can manually push work item details when creating a release (the “legacy” system).

But I suggest that you do not consider the previous system as legacy/obsolete/removeable. IMHO, you should just suggest the new method (official issue tracker connector and buildinformation) for new, cloud based systems, but still support the case where everything is pushed in the create release step, and redirect people with advanced scenarios which does not fit the new system to this option.

I was trying to migrate to the new method because I feared that the release note management in the “create release” could have been removed in a future version. It seems I should stay with this method if making our issue tracking service available from octopus is a no-go.

Anyway, many thanks for your advices, you can consider this question as solved.