Azure Boards
Azure Boards is Microsoft’s work-item tracker, part of Azure DevOps Services. Work items are addressed by sequential numeric ID (#12345) inside a project, often prefixed with AB# in commit messages to disambiguate from GitHub-style issue references.
Forgejo side: external issue tracker
Repo Settings → “Advanced Settings” → External issue tracker.
| Field | Value |
|---|---|
| External issue tracker URL | https://dev.azure.com/<your-org>/<your-project>/_workitems/edit/{index} |
| External issue tracker URL format | https://dev.azure.com/<your-org>/<your-project>/_workitems/edit/{index} |
| External issue tracker number format | Regexp |
| External issue tracker number format regexp | `(?:AB |
The regex catches both AB#12345 (the canonical Azure Boards reference) and the legacy #12345 form. Replace <your-org> and <your-project> with your Azure DevOps organisation + project slugs.
Recommended commit-message format
refactor: extract token-exchange path
AB#34521The AB# prefix is a soft convention from the Azure DevOps team’s docs; if your team uses bare #12345 instead, the regex above catches both — but mixing both styles in one repo confuses downstream tooling.
Tracker side: Service Hooks (optional)
To make Azure Boards show the linked commits/PRs on each work item:
- Azure DevOps → Project Settings → Service hooks → + Add subscription.
- Service: Web Hooks (last option in the list — Azure doesn’t ship a native “Forgejo” service hook, but Web Hooks accepts any URL).
- Trigger: leave as “Code pushed” / “Pull request created” depending on what you want surfaced.
- URL: in fremforge create an outbound webhook FIRST (admin → Webhooks → Add Webhook) with target
https://dev.azure.com/<your-org>/<your-project>/_apis/git/repositories/<your-repo-id>/links— Azure’s link-attachment endpoint. Paste that URL into the Service Hook subscription.
The hop is asymmetric (Forgejo → Azure) because Azure DevOps doesn’t poll external repos for Forgejo; it expects pushes notified by your CI/code-host. fremforge’s outbound webhook is the right primitive.
Sub-processor implications
Azure DevOps Services control plane is Microsoft Azure (US-Central + EU-West regions per data residency). When you wire fremforge to Azure Boards:
- Commit metadata + repo references flow to Microsoft Azure.
- Add Microsoft Corporation to your sub-processor register as handling Personal Data (commit author email, commit message).
- fremforge’s DPA explicitly excludes Microsoft sub-processors (per the trust page sovereignty posture) — your tenant DPA addendum stands alone for this leg.
For sovereignty-sensitive workloads, consider Plane (self-hosted EU-deployable, Apache 2.0) as an Azure Boards alternative.
What this doesn’t do
- No auto-close on merge (Azure Boards supports automation via Work Item Automation rules; configure the rule against the inbound Web Hook payload).
- The Azure DevOps Repos-native integration (state transition on PR merge) does NOT carry across to Forgejo — that linkage is specific to Repos. The fremforge integration is one-way (commit/PR → work item link) plus customer-driven automation for the reverse.
- Sprint / iteration / area-path sync is not in scope. Those are Azure-internal concepts that don’t map cleanly to a Git host.