Add Azure DevOps support with shared core comment logic

[tupe12334]

Summary

Add support for Azure DevOps Pipelines so the Worktree workspace link comment is posted on new work items, while keeping the core comment-building logic shared between platforms.

Motivation

Currently src/index.mjs is tightly coupled to GitHub Actions (@actions/core, @actions/github). Users on Azure DevOps should get the same experience — a comment with an Open workspace link posted automatically when a work item is created.

Proposed Architecture

Extract platform-agnostic logic into a shared module and implement thin platform adapters:

src/
  comment.mjs          # shared: builds the comment body given { owner, repo, issue }
  github/index.mjs     # GitHub Actions adapter: reads context, calls Octokit
  azure/index.mjs      # Azure DevOps adapter: reads pipeline env vars, calls ADO REST API

Shared (comment.mjs)

• buildCommentBody({ owner, repo, issue }) — returns the markdown string with the badge and footer
• No platform dependencies

GitHub adapter (github/index.mjs)

• Reads owner, repo, issue_number from @actions/github context
• Guards on issues.opened event
• Posts comment via Octokit (issues.createComment)
• Logs via @actions/core

Azure DevOps adapter (azure/index.mjs)

• Reads owner, project, workItemId from ADO pipeline environment variables (SYSTEM_TEAMPROJECT, BUILD_REPOSITORY_NAME, etc.)
• Guards on work item created event (ADO service hook or pipeline trigger)
• Posts comment via Azure DevOps Work Item Comments REST API
• Logs via console or azure-pipelines-task-lib

Open Questions

• Should the Azure adapter be a separate action (new action.yml) or a new entry point in this repo?
• Authentication: PAT vs service connection for ADO?
• ADO equivalent of "issue opened" trigger — service hook vs pipeline step?

[github-actions]

A workspace is ready for this issue.

_{Powered by Worktree · Install}

[tupe12334]

Resolved: same repo, separate entry points — no filename conflict.

• GitHub Actions uses action.yml (already exists)
• Azure DevOps tasks use task.json (new file)

Both manifests can live at the repo root and point to their respective adapter entry points (dist/github/index.mjs and dist/azure/index.mjs). The shared comment.mjs core is bundled into both.

[tupe12334]

Resolved: use System.AccessToken — the built-in ADO pipeline token, equivalent to github.token.

• No user ownership, no expiry, no manual rotation
• Enabled per-step: env: AZURE_TOKEN: $(System.AccessToken)
• PATs are user-tied and expire — avoid for automation
• Service connections are for external services, not the ADO REST API itself

The task.json input will mirror the GitHub action.yml:

{
  "name": "token",
  "type": "string",
  "defaultValue": "$(System.AccessToken)"
}

[tupe12334]

Resolved: Option B — Service Hook → Pipeline trigger → Task step.

Azure Pipelines have no native "work item created" trigger, so a service hook is used to fire the pipeline:

Work item created
  → ADO Service Hook ("Azure Pipelines" type, triggers pipeline)
    → pipeline runs azure-pipelines.yml
      → Worktree task step posts comment via ADO Comments REST API

• Consistent with the GitHub Action model (task in YAML)
• Requires task.json (ADO task manifest)
• User setup: configure service hook once + add Worktree task to pipeline YAML

[tupe12334]

After discussion, we've decided to implement Azure DevOps support in a separate repository (e.g. worktree-io/azure-comment-action) rather than extending this one.

Reasons:

• Keeps this repo focused on GitHub Actions only
• Azure DevOps tasks have a different release/publish lifecycle (task.json vs action.yml, separate marketplace)
• Avoids coupling the GitHub Action build to ADO tooling and dependencies
• Each adapter can version independently

The shared buildCommentBody logic can live in a small shared package or be duplicated across the two repos given its simplicity. The ADO adapter work will be tracked in the new repo.