Skip to main content
Private preview. fremforge is in private preview — invited customers only. Content is still subject to change. Request access →
Azure Boards

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.

FieldValue
External issue tracker URLhttps://dev.azure.com/<your-org>/<your-project>/_workitems/edit/{index}
External issue tracker URL formathttps://dev.azure.com/<your-org>/<your-project>/_workitems/edit/{index}
External issue tracker number formatRegexp
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#34521

The 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:

  1. Azure DevOps → Project SettingsService hooks+ Add subscription.
  2. Service: Web Hooks (last option in the list — Azure doesn’t ship a native “Forgejo” service hook, but Web Hooks accepts any URL).
  3. Trigger: leave as “Code pushed” / “Pull request created” depending on what you want surfaced.
  4. URL: in fremforge create an outbound webhook FIRST (admin → WebhooksAdd 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.