Support Azure Devops Issues Importer Bridge #1542

Activity

1. sudoforge

   added

   area/bridgeRelates to bridges (generic)Relates to bridges (generic)

   kind/featureRelates to a new featureRelates to a new feature

   triage/needs-priorityMissing label: priotityMissing label: priotity

   triage/needs-approvalNeeds approval before staffingNeeds approval before staffing

   on Mar 27, 2026
2. sudoforge commented on Mar 27, 2026

   

   sudoforge

   on Mar 27, 2026

   Contributor

   More actions

   Thanks for opening this as a feature request. We are not currently developing new internal bridges, as there exists a (future) plan for exposing a "plugin interface" so that bridges can be built by the community and seamlessly integrated with git-bug. You can read more about that here: #1391 (comment)

   That said, if you have the bandwidth to build this and maintain it in-tree until that interface is released (at which point it can/will be moved out-of-tree), we can merge it in on the condition and understanding that you would be responsible for issues opened that are related to it. We're always looking for new contributors!
3. timpara commented on Sep 2, 2026

   

   timpara

   on Sep 2, 2026

   More actions

   Hi @sudoforge, thanks for the clear answer earlier.

   I would like to pick this up. I accept the terms: I will build it, keep it in-tree until the external plugin interface is ready, and help move it out-of-tree when that lands. I will also handle the issues people open about this bridge.

   My plan:

   • A two-way bridge (import and export), based on the existing Jira bridge, since Azure Boards is also a REST tracker with projects, states, and custom fields.
   • PAT auth first. I will store a personal access token through the existing auth credential store (token kind) and keep the first version simple. OAuth can come later.
   • Incremental import using a WIQL query on System.ChangedDate with the since timestamp the core already passes to the importer. Work items become bugs, comments become comment operations, state maps to status, and tags map to labels.
   • Export creates and updates work items with the JSON Patch API and posts comments. It stores metadata keys on the operations so nothing is exported twice.

   Before I write too much code, I want to confirm a few things so I build something you would merge:

   1. Bridge name. Do you prefer azuredevops, ado, or azure for the target and config keys? It is hard to change later, so I want to match your preference.
   2. Client dependency. You said vendored bridge clients that break the build are a real pain. I plan to write a small net/http REST client for only the endpoints I need, instead of adding the large official azure-devops-go-api SDK. Is that the direction you want?
   3. First PR scope. Would you rather have one PR with both import and export, or import first and export in a follow-up?

   I have forked the repo and will open a draft PR once the skeleton compiles. Tell me if you want any of this changed.