Skip to content
This repository has been archived by the owner on May 8, 2023. It is now read-only.

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

Open
5 tasks done
danefalvo opened this issue Jun 10, 2020 · 2 comments
Labels
kind/bug Something isn't working

Comments

@danefalvo
Copy link

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.

Work Items issue

Affected versions

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

Links

Discovered when investigating the following: OctopusDeploy/OctoTFS#179

@thedewi
Copy link
Contributor

thedewi commented Jun 11, 2020

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
Copy link
Author

danefalvo commented Jun 12, 2020

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)
FixedIssue7

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

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

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).

@kengel100 kengel100 transferred this issue from OctopusDeploy/Issues Apr 22, 2021
@kengel100 kengel100 added the kind/bug Something isn't working label Apr 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants