renovate
renovate copied to clipboard
renovatebot
Support issues for Azure platform
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?
These functions need to be implemented: https://github.com/renovatebot/renovate/blob/fbbbce608e5df637ac5a6447774d38e03b2e79fc/lib/platform/azure/index.ts#L699-L721
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.
@JamieMagee do you think the dependency dashboard would make sense as a work item?
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^1. 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.
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.
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.
This might also make more sense, even as a read-only dashboard, with the recent changes to include all detected dependencies.
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.
So checkboxes display ok, the only problem is that they're not interactive?
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.)
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)
@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?
Just another idea... would it be possible to use the Azure DevOps wiki for the dashboard? It supports a task list.
The wiki is a git repository behind the scenes, so it should be possible.
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.
@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
The documentation mentions that "Dependency Dashboard" feature lacks support for Bitbucket Server (https://docs.renovatebot.com/key-concepts/dashboard/#supported-platforms) and refers to this issue.
Is this issue only to create support for Azure DevOps as the title says or does it cover Bitbucket server as well?
Is there are separate issue to create support for Bitbucket Server?
I haven't tested yet, because I saw this comment in the docs that "Dependency Dashboard" is not supported for Bitbucket server? Is that true or not?
It's not supported because issues aren't supported. And I thought issues aren't supported because they don't exist on Bitbucket server
Got it. Once this: #3796 is closed, would it enable adding "Dependency Dashboard" support for Bitbucket Server? Or does it require issues to be supported natively by the SCM (wrt. GitHub issues)?
One of the important functionalities of the Dependency Dashboard is the interactive checkboxes. So Jira could at best support just a static list of dependencies and branches but not allow the interactivity.
Marking this conversation as off-topic in this issue
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.
https://github.com/renovatebot/renovate/pull/15876
I think what could also help is make task on PR creation or after. So people could just do it on it own.
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.
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).
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
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
