Commit Message is removed if referencing DevOps Work Item from different Project or that does not exist

[danefalvo]

Are you a customer of Octopus Deploy? Don't raise the issue here. Please contact our support team so we can triage your issue, making sure it's handled appropriately.

Prerequisites

• I have verified the problem exists in the latest version
• I have searched open and closed issues to make sure it isn't already reported
• I have written a descriptive issue title
• I have linked the original source of this report
• I have tagged the issue appropriately (area/*, kind/bug, tag/regression?)

The bug

in Azure DevOps, If a work item is linked to a code commit through any of these methods:

1. Edit a pull request in Azure DevOps, and use the Work Items panel to select a work item.
2. Edit a work item in Azure DevOps, and use the Development panel to add a pull request link (before build), or a commit link, or a build link.
3. When you commit code. If you enable the repository setting: Automatically create links for work items mentioned in a commit comment under Project Settings (Repositories), you can include # followed by a valid work item ID in the commit message. For example, git commit -a -m "Fixing bug Projects - hide/prevent Create release when no process defined Issues#42 in the web client".
   (https://octopus.com/docs/managing-releases/issue-tracking/azure-devops#how-azure-devops-integration-works)

If the Work Item is located in a different project, or if the Work Item doesn't exist (method 3 above only), then the entire commit message is stripped when the Metadata is pushed to the Octopus Deploy server.

What I expected to happen

If the Work Item does not exist then the "#XX" should appear but not as a link within Octopus. If the Work Item exists in another project, the link should still appear.

Steps to reproduce

1. Create a pipeline in Azure DevOps that uses the "Push Package to Octopus", "Push Package Build Information to Octopus" and "Create Release".
2. Commit a change to the pipeline with a message that references a non-existant work-item.
   Git Commit -m "Fixing issues Active directory users cannot log in after 1.6 to 2.0 migration Issues#456 and Variables can no longer be filtered  Issues#457"
3. Run the Pipeline and Wait for the Push Package Build Information step to complete.
4. Look at the Work Items section in the "Releases" section of the project. It should be empty.

The Work Items don't exist in the api for the release either.

Screen capture

2.2.8 was committed with
git commit -m "#6 just another Issue To Do"

2.2.9 was committed with
git commit -m "#6 OctopusDeploy/Issues#7 more issues to fix"

Work Item OctopusDeploy/Issues#7 existed in a different project.

Affected versions

Tested against the latest cloud version. (v. 2020.2.11)

Links

Discovered when investigating the following: OctopusDeploy/OctoTFS#179

[thedewi]

I've got some context on how Azure DevOps Work Item integration works. For that issue tracker, work items are requested from Azure DevOps, rather than parsed out of the commits sent to Octopus. This is because Azure DevOps has a concept of those linkages itself, and parses commit messages itself (if configured to do so), so our approach has been to gel with that model and trust it.

In the screen capture example where the commit referenced two work items and didn't show up, do either of the linkages to work items show up within Azure DevOps? i.e., is Octopus failing to reflect the relationship within Azure DevOps, or was Azure DevOps unable to recognize it in the first place?

For cases with just one reference outside the project, could you expand on what that looks like within Azure DevOps? Is that kind of reference something it supports?

[danefalvo]

Within the Azure Devops Commits section, the commit messages appear in full.

Commit messages with references to work-items in alternate projects, have the correct links applied to the work-item and are stylised to represent the type of work-item. (I.E. One Reference outside of the current project)

Commit messages with references to work-items that do no exist in any project appear as a standard hyperlink. i.e # 372.

The link itself tries to link to a work-item within the current project. Navigating to the link returns an error.

Just FYI - two Work-Items attempted to be linked within the same commit message with 1 work-item being in the current project and 1 work-item being in an alternate project, also appear fully stylised as in the first image. I would assume it's all about the user permissions as to whether they appear stylised or not (and possibly what breaks the Octo integration).