Skip to content

feat/add az support#1256

Open
mikeyroush wants to merge 7 commits intomax-sixty:mainfrom
mikeyroush:feat/add-az-support
Open

feat/add az support#1256
mikeyroush wants to merge 7 commits intomax-sixty:mainfrom
mikeyroush:feat/add-az-support

Conversation

@mikeyroush
Copy link
Copy Markdown

Summary

  • Add Azure DevOps support for pr:<N> switching and CI status integration.
  • Fix worktree name resolution by stripping remote prefixes in resolve_worktree_name.
  • Update docs to mention Azure DevOps behavior in pr:<N> help text and CI status output.

Context

This change set introduces Azure DevOps parity for PR-based workflows and CI visibility, plus a small correctness fix in worktree name normalization.

Commits included:

  • a8052d03 — feat: add Azure DevOps support for pr: switching and CI status
  • f201bd5c — fix: strip remote prefix in resolve_worktree_name
  • 239fa127 — docs: mention Azure DevOps in pr:<N> help text and CI status

Fixes #1144

Test plan

  • pre-commit run --all-files passes
  • cargo test --test integration test_skill_files_are_in_sync_with_docs passes
  • Manual validation:
    • wt switch pr:<N> works against Azure DevOps remotes
    • CI status displays correctly for Azure-backed branches
    • Existing GitHub/GitLab pr: flows remain unaffected

mroush and others added 3 commits March 4, 2026 01:02
`wt switch origin/branch-name` now resolves to `branch-name` instead of
treating the full string as a branch name. This matches `git switch`
behavior where `origin/foo` creates a local tracking branch named `foo`.

Previously, `wt switch -c origin/branch-name` would create a new local
branch literally named `origin/branch-name` based on the default branch.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add Azure DevOps as a first-class provider alongside GitHub and GitLab:

- Detect Azure DevOps repos from remote URLs (dev.azure.com,
  ssh.dev.azure.com, *.visualstudio.com)
- `wt switch pr:<N>` resolves Azure DevOps PRs via `az repos pr show`
  with auto-detection of organization from git remotes
- CI status detection via `az pipelines runs list` and `az repos pr list`
- Auto-detect platform from remote URLs — no configuration needed
- `wt config show --full` reports `az` tool and auth status

Closes max-sixty#1144

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Update switch command help to document Azure DevOps PR support,
update CI status references, and sync generated docs.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Copy link
Copy Markdown
Collaborator

@worktrunk-bot worktrunk-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well-structured addition that closely follows the existing GitHub/GitLab patterns. The detect_pr_provider refactor to auto-detect from remote URLs is a nice improvement over hardcoding GitHub.

A few observations:

AzPipelineRun.url — API URL vs web URL. The Azure DevOps REST API's url field on build resources is typically the API endpoint (e.g., https://dev.azure.com/{org}/{project}/_apis/build/Builds/{id}), not the web URL. The GitHub and GitLab CI modules use html_url/web_url respectively. Worth verifying that az pipelines runs list --output json gives a clickable browser link here — if not, you'd need to either extract _links.web.href from the response or construct the web URL manually (like url_from_web does for PRs).

pr:N now works on GitLab repos toodetect_pr_provider includes GitLab, so pr:42 on a GitLab-origin repo will resolve MR #42. This is a reasonable UX improvement, but the help text only says "GitHub/Azure DevOps PR". Either mention GitLab or document this as intentional.

PlatformData::AzureDevOps::host is hardcoded to "dev.azure.com" even when the repo uses a *.visualstudio.com remote. The field isn't read downstream currently, so this isn't a bug today — but it's a trap for future code. Consider either populating it from the actual remote host or removing it if it's not needed.

Copy link
Copy Markdown
Collaborator

@worktrunk-bot worktrunk-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI is failing with two clippy::collapsible_if errors and a cargo fmt issue. Both are in PR code — see inline suggestions.

  - Fix PR URLs missing _git segment in Azure DevOps links
  - Fix doubled project name in CI status PR URL
  - Fix early return in detect_azure_org on blank remote lines
  - Collapse nested if-let per clippy collapsible_if lint
  - Use actual host from API response instead of hardcoded dev.azure.com
  - Construct web URL for pipeline runs instead of using REST API URL
Copy link
Copy Markdown
Collaborator

@worktrunk-bot worktrunk-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previous feedback was well addressed — collapsible-if lints, comment wording, host detection from web_url, and the web URL construction for pipeline runs. One remaining issue with the pipeline URL.

- Add missing project segment to Azure pipeline web URL
- Check --base conflict before detect_pr_provider() so the error
  fires even without a forge remote configured
- Add GitHub/GitLab remote URLs to PR/MR error-path tests so
  detect_pr_provider() succeeds and mocks are exercised
- Update snapshots for Azure DevOps additions to help text,
  config show, and CI platform validation messages
- Collapse nested if-lets per clippy

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Copy link
Copy Markdown
Collaborator

@worktrunk-bot worktrunk-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previous feedback was well addressed — pipeline URL now includes the project segment, comment wording is fixed, host detection uses web_url, and the --base conflict check was moved before network calls (good improvement).

One remaining doc gap: the shortcuts table in after_long_help (line 298 of src/cli/mod.rs) still describes pr:{N} as "GitHub PR #N's branch", but pr: now works for Azure DevOps too. The arg help on line 397 already correctly says "GitHub/Azure DevOps PR" — the shortcuts table should match:

| `pr:{N}` | GitHub/Azure DevOps PR #N's branch |

Copy link
Copy Markdown
Collaborator

@worktrunk-bot worktrunk-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI is failing on both Linux and Windows — cargo fmt reports formatting issues. This needs a cargo fmt pass on the changed files before the PR can merge.

- Run cargo fmt on all changed files
- Update shortcuts table to say "GitHub/Azure DevOps PR" (was "GitHub PR")
- Sync docs and update help snapshot

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
/// If `name` starts with `{remote}/` where `{remote}` is a configured remote,
/// returns the branch name without the prefix. This matches `git switch` behavior
/// where `origin/foo` creates a local tracking branch named `foo`.
fn strip_remote_prefix(&self, name: &str) -> Option<String> {
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@worktrunk-bot can you explain the change here? does it have a wider blast radius than just Azure? (also make transparent any other changes with a blast radius bigger than Azure)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was the issue I was trying to fix:

❯ wt switch origin/feat
✗ No branch named origin/feat
↳ To create a new branch, run wt switch --create origin/feat; to list branches, run wt list --branches --remotes

The change does affect all platforms, not just Azure — it strips origin/ prefixes from branch names when resolving worktree names. It's not related to Azure support, but seemed like low hanging fruit.

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great find! this indeed was a bug. I think it should be generally fixed by #1266 ...

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. I can work on reverting this section.

- De-emphasize Azure DevOps in docs: replace full section with single
  line at bottom of GitHub section, revert shortcuts table
- Use repo.primary_remote() instead of hardcoded "origin" in
  detect_pr_provider() to respect checkout.defaultRemote

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@max-sixty
Copy link
Copy Markdown
Owner

@mikeyroush Did I drop this?? I'm very sorry if so...

@worktrunk-bot could you update for the latest changes, resolve merge conflicts, etc?

@max-sixty
Copy link
Copy Markdown
Owner

@worktrunk-bot please re the above

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Feat: Azure DevOps integration

4 participants