Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Azure - Support linked work items #3395

Closed
JamieMagee opened this issue Mar 16, 2019 · 8 comments · Fixed by #3542
Closed

Azure - Support linked work items #3395

JamieMagee opened this issue Mar 16, 2019 · 8 comments · Fixed by #3542
Labels
priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others type:feature Feature (new functionality)

Comments

@JamieMagee
Copy link
Contributor

What would you like Renovate to be able to do?
Azure DevOps supports branch protections, and one of these protections is that every pull request has to have a linked work item (See details here). I would like to have renovate link a work item to each PR that it opens

Describe the solution you'd like
I would like to have a work item id in the renovate config, that could be linked to each pull request that is opened against that repository. I think having renovate create a work item would be too much noise, and simply having a single work item that renovate can link all it's PRs against would be sufficient

Describe alternatives you've considered
An alternative would be for renovate to create individual work items, and link them to an individual PR. However, I think this would create too much noise. Additionally in my organisation there are restrictions on which fields need to be filled in when a work item is created, which would also add to the complexity of renovate creating work items.
@rarkins rarkins added type:feature Feature (new functionality) ready priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others labels Mar 17, 2019
@rarkins
Copy link
Collaborator

rarkins commented Mar 17, 2019

I agree that it sounds best to have a single work item created out of band, which is then used in every create PR call.

Sounds like we'd need a new configuration option, as it doesn't fit into any existing config I can think of.

The remaining question is how it is passed around - e.g is it set once at the start of a repo run or is it passed through every call until it is eventually passed to the create PR function.

@JamieMagee
Copy link
Contributor Author

I think it would be simpler to implement if this was just set once at the start of the repo run.

@rarkins
Copy link
Collaborator

rarkins commented Mar 18, 2019

I'm wondering if the Renovate "master issue" (currently undocumented and about to be released - see example here: #2958) could serve as the work item? Note that for Azure I don't think its markdown supports the checkboxes like GitHub and GitLab do, so it would not be a fully functional master issue on Azure DevOps.

Alternatively we can just have a new config option azureWorkItem or azureWorkItemId that is passed as part of platform.initRepo. If set then we create PRs referencing it and the user is responsible for creating the work issue in advance.

@JamieMagee
Copy link
Contributor Author

Possibly, but I can only see how it would work if masterIssue had dual purpose, as a boolean for platforms where it's possible for renovate to create issues, and a number on Azure DevOps, where it's not really possible to create issues on the fly. Unless there was some other configuration property masterIssueId, but then that's just Azure DevOps specific anyway, and it might just as well be azureWorkItem/azureWorkItemId.

I think that having an azure specific configuration property, that is passed at platform.initRepo, might be the cleanest option. I can't see renovate ever being able to support work item creation on Azure DevOps. Like Jira, it's just too customisable.

@JamieMagee
Copy link
Contributor Author

@rarkins I'll go ahead and implement an azureWorkItemId property.

@JamieMagee
Copy link
Contributor Author

After some investigation, it's currently not possible to link work items with the API. See https://developercommunity.visualstudio.com/content/idea/366535/link-pull-request-to-work-items-using-the-rest-api.html

@rarkins
Copy link
Collaborator

rarkins commented Apr 12, 2019

Closing until this is possible

@rarkins rarkins closed this as completed Apr 12, 2019
@rarkins rarkins removed the ready label Apr 12, 2019
@JamieMagee JamieMagee mentioned this issue Apr 14, 2019
Merged
rarkins pushed a commit that referenced this issue Apr 15, 2019
@JamieMagee @rarkins
feat(azure-devops): link to an existing work item when creating PRs (#…
6ca8991 
…3542)

Looks like I was (happily) wrong about this. There is currently no API to add a work item to a PR as an individual action. Instead you have to link the work item when creating the PR, or by using the `updatePullRequest` API.

I've tested with the default (0), a non-existent work item ID, and a real work item ID, and they all work with this implementation.

Fixes #3395
@renovate-bot
Copy link
Collaborator

🎉 This issue has been resolved in version 15.16.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others type:feature Feature (new functionality)
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat(azure): link to an existing work item when creating PRs
3 participants
@JamieMagee @rarkins @renovate-bot