Support issues for Azure platform

[zharinov]

What would you like Renovate to be able to do?

Renovate should support issues on azure devops. That way dependency dashborad and other config issues can be created by renovate.

Did you already have any implementation ideas?

[viceice]

These functions need to be implemented:

renovate/lib/platform/azure/index.ts

Lines 699 to 721 in fbbbce6

	/* istanbul ignore next */
	export function findIssue(): Promise<Issue | null> {
	logger.warn(`findIssue() is not implemented`);
	return null;
	}
	/* istanbul ignore next */
	export function ensureIssue(): Promise<EnsureIssueResult | null> {
	logger.warn(`ensureIssue() is not implemented`);
	return Promise.resolve(null);
	}
	/* istanbul ignore next */
	export function ensureIssueClosing(): Promise<void> {
	return Promise.resolve();
	}
	/* istanbul ignore next */
	export function getIssueList(): Promise<Issue[]> {
	logger.debug(`getIssueList()`);
	// TODO: Needs implementation (#9592)
	return Promise.resolve([]);
	}

[fmustapha]

Hello, any updates on this. I am getting the same warning in Azure Devops. The pipeline built successfully but I do not see any PRs created.

[rarkins]

@JamieMagee do you think the dependency dashboard would make sense as a work item?

[JamieMagee]

I looked into this before and Azure DevOps is almost too configurable for this.

To give you an idea, Azure DevOps comes pre-configured with four processes¹. However, this is just a starting point and you can completely customize all your work items and hierarchy. This also includes mandatory fields. In which case, what should they be? Of course we can query for a list of work item types, choose one, query for required work item fields, and set them randomly, but the resulting work item might not make much sense? Or might pop up in a query where it's not supposed to. And trigger some other processes.

All of the above is why I implemented azureWorkItemId instead of asking Renovate to create work items. It's easier for users to give us an existing work item ID that is pre-configured to meet their workflow.

As for dependency dashboards, I also investigated that. Azure DevOps does support rendering markdown and HTML in a work item description. But the checkboxes aren't interactive. That makes the dependency dashboard read-only, and not useful IMO.

Footnotes

1. https://docs.microsoft.com/en-us/azure/devops/boards/work-items/guidance/choose-process?view=azure-devops&tabs=basic-process ↩

[ecraig12345]

Would it be possible to add a dependencyDashboardAzureWorkItemId or something like that? Basically the user manually creates an appropriate work item, then Renovate edits the description.

[rarkins]

We could definitely attempt that idea, but I assume keeping in mind that the checkboxes won't be possible so we'd need to adjust our markdown a bit to accommodate.

[JamieMagee]

This might also make more sense, even as a read-only dashboard, with the recent changes to include all detected dependencies.

[ecraig12345]

A read-only dashboard would be better than nothing, but being able to use the dashboard to take actions is a big part of the appeal. Even if I had to manually edit the markdown to "check" checkboxes, that might still be useful.

[rarkins]

So checkboxes display ok, the only problem is that they're not interactive?

[ecraig12345]

I had to go try it out since I haven't actually used Azure DevOps work items in awhile (my team primarily works on github, but I'm helping set up Renovate for some ADO repos).

It looks like the "Description" field is displayed with a rich text editor and stored as HTML, not markdown. (Probably the same for other multi-line text fields.) It's possible to save markdown text into the field using the API, but it will display as plain text rather than being nicely formatted...which might be sort of usable, but not great.

In theory Renovate could also render the markdown into HTML and save that into the field. That would be a decent approach for a read-only dashboard, but it wouldn't help with checkboxes: if you put an <input type="checkbox"> in the HTML, it will render, but checking it doesn't actually modify the underlying HTML.

(There's an extension that fakes markdown support in work item fields, but what that actually does is convert to HTML as you type and save a ton of CSS and HTML in the field.)

[Nisden]

Just injecting another idea here, would it be possible to use a "dummy" pull request instead of work items?
I just noticed that pull requests in Azure DevOps actually supports markdown with checkbox'es (And it saves the changes)

[rarkins]

@ecraig12345 I think that converting from markdown to html is something we could add as part of our azure-specific code for ensureIssue()

@Nisden that's an interesting idea! @JamieMagee wdyt?

[agilenut]

Just another idea... would it be possible to use the Azure DevOps wiki for the dashboard? It supports a task list.

[JamieMagee]

The wiki is a git repository behind the scenes, so it should be possible.

[danielmertens]

Is there an update on this item? I would like to have this functionality in Azure Devops.
If not, I could see if I can give it a go.

[rarkins]

@danielmertens a PR for this would be very welcome! I've left this as status:requirements because it sounds like there might be some requirements gathering or decision making you find along the way, but it is OK to start.

BTW I've also sent you an invite to our contributor-only Slack channel in case you would like to join to discuss

[waszakCeneo]

What would be good if this was also implemented "Create new work item for each PR "
From comments in that PR it is said to scope this in this issue.

#15876

I think what could also help is make task on PR creation or after. So people could just do it on it own.

[sheldonhull]

What would be good if this was also implemented "Create new work item for each PR " From comments in that PR it is said to scope this in this issue.

#15876

I think what could also help is make task on PR creation or after. So people could just do it on it own.

Just going to mention that Azure DevOps Boards is a pretty big challenge and personally I wouldn't find much value in it as a long-term Azure Repos + Renovate user. In the multiple companies I've worked at there tends to be customization and required fields & rules in this that would be difficult to handle. This is far different than github issues which are very unrestricted and freeform.

I've not yet worked at any place that used vanilla backlog type settings.

The required fields can actually block the automatic resolution of a work-item by merging the PR so it becomes another things to go track and manually edit, and no one would know without trying to manual edit and transition the file. There's additionally rule validation logic that is a UI for building conditional rules.

The pull request itself is the most important piece to me.
The dependency dashboard linking to an existing long-lived item is satisfactory.

[gioce90]

So in this discussion I see that some of you consider Azure devops's Work items not a good choice because there is a rich html editor that does not supports checkboxes.
There is a Feature request on MS dev community to embrace Markdown. Upvotes if you want.
Ultimately MS introduced markdown in PR's Description and Comments area. Other places who uses MD are reported here

What about the idea of using Azure DevOps wiki? There are two kind of: project wiki and code wiki (the last one have a git repository behind the scenes).

[RolfMoleman]

If you’re proposing to use wilis why not have a common renovate directory of some sort that gets mounted as a code based wiki from the relevant repo?

That shouldn’t be too complicated via the rest apis

[rbev]

What about the idea of using Azure DevOps wiki? There are two kind of: project wiki and code wiki (the last one have a git repository behind the scenes).

In fact the project wiki is ALSO a git repository, it just isn't visible directly.
It's path/name is predictable but you can also see the repo URL if you query the api

[gioce90]

Okay fine, there is always a repo behind the scenes. So... is feasible to use wiki as solution for the dependency dashboard?

Otherwise, we need to wait the 2025 Q1, following this comment:

This feature has been added to our public roadmap. The feature is current scheduled for Q1 of 2025 with hopes to have it done sooner.

[agilenut]

Okay fine, there is always a repo behind the scenes. So... is feasible to use wiki as solution for the dependency dashboard?

Otherwise, we need to wait the 2025 Q1, following this comment:

This feature has been added to our public roadmap. The feature is current scheduled for Q1 of 2025 with hopes to have it done sooner.

I’d vote for wiki over work items anyway. Most places I’ve worked do not use work items. Just make sure to make the path of the wiki pages configurable so it doesn’t conflict with other wiki pages.

[Aspyryan]

Any update on this? I see that it is supported now: https://devblogs.microsoft.com/devops/markdown-for-large-text-fields-private-preview/

[github-actions]

Hi there,

Please do not post comments like: "Any update on this?" or "When will this be fixed?".

If you're asking because you want to know if there's been some progress, then please know that we work in the open in this repo. If there was an update to this Discussion or Issue, you would see it already. So please don't ask "just in case".

If you're asking because you want to get our attention, then please don't do that either. It wastes maintainer time and pollutes the repo. You're welcome to fix issues yourself, hire someone to help you, or wait for someone else to do the work. You're not welcome to post the equivalent of "Hey, someone else should really do something about this".

If you are a paying Mend.io customer, contact your support or customer success representative, and tell them this issue is important to you.

We expect everyone to follow these rules, no matter if you use the free tiers, or are a paying Mend customer. Please read our Code of Conduct, how we prioritize work to learn more about how we prioritize what to work on.

Thanks, the Renovate team