Skip to content

Add Azure DevOps support with shared core comment logic #1

Open

Description

@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?

Activity

  1. github-actions commented on Feb 23, 2026

    @github-actions

    A workspace is ready for this issue.

    Open workspace →

    Powered by Worktree · Install

  2. tupe12334 commented on Feb 23, 2026

    @tupe12334
    MemberAuthor

    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.

  3. tupe12334 commented on Feb 23, 2026

    @tupe12334
    MemberAuthor

    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)"
    }
  4. tupe12334 commented on Feb 23, 2026

    @tupe12334
    MemberAuthor

    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
  5. added a commit that references this issue on Feb 23, 2026
    70ced77
  6. tupe12334 commented on Feb 23, 2026

    @tupe12334
    MemberAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions