[Fix] Unblock Azure DevOps onboarding: environment config, cloning, and webhooks - #30
Merged
Merged
Conversation
|
No new code issues found. See task |
Contributor
|
All contributors have signed the CLA. |
Member
Author
|
I have read the CLA Document and I hereby sign the CLA |
…nd webhooks
Four fixes found by exercising a fresh Azure DevOps connection end to end:
- Environment configs rejected Azure DevOps repositories: the repository
schema required exactly owner/repo, but ADO full names are always
organization/project/repo (and GitLab subgroups have 3+ segments).
Relax to two or more non-empty slash-separated segments.
- Worker clones of ADO repositories failed with "could not read
Password": ADO remoteUrl embeds the organization as URL userinfo
(https://org@dev.azure.com/...), which never matches the worker's
insteadOf credential-proxy rewrite. Strip userinfo at sync time and
defensively in the worker clone path via a shared helper.
- Every ADO webhook delivery 500'd at the web proxy: ADO sends
Expect: 100-continue, which undici's fetch rejects
(UND_ERR_NOT_SUPPORTED). Drop the header before forwarding.
- ADO comment webhooks failed schema validation: deliveries carry the
comment object directly as `resource` (even at resourceVersion 1.0),
not the documented { comment, pullRequest } nesting. Rehydrate the
pull request from the resource links before parsing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
daniel-lxs
force-pushed
the
fix/ado-integration-onboarding
branch
from
July 9, 2026 14:18
935e986 to
92cade5
Compare
…n-onboarding # Conflicts: # packages/ado/src/api.ts
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Four fixes found by exercising a fresh Azure DevOps connection end to end (org + PAT → repo sync → environment mapping → service hooks → manual task → PR automation → comment mentions). Each fix was verified live against a real
dev.azure.comorganization.1. Environment configs rejected Azure DevOps repositories
environmentRepositoryConfigSchemarequired exactlyowner/repo, but ADO full names are alwaysorganization/project/repo— so a synced ADO repo could never be added to an environment through YAML create/update, which also gates PR automation. GitLab subgroup repos (3+ segments) had the same latent problem. The regex now accepts two or more non-empty slash-separated segments; everything downstream already keys off exactfullNameequality.2. Worker clones failed with
could not read PasswordADO
remoteUrlembeds the organization as URL userinfo (https://org@dev.azure.com/...). Git'sinsteadOfis a literal prefix match, so the worker's credential-proxy rewrite never fired and git prompted for a password it couldn't get. Fixed at both ends with a sharedstripCloneUrlUserInfohelper: sync stores a cleancloneUrl, and the worker strips userinfo defensively before cloning (covers rows synced before this fix).3. Every ADO webhook delivery 500'd at the web proxy
Azure DevOps service hooks send
Expect: 100-continue; undici'sfetchrejects the header outright (UND_ERR_NOT_SUPPORTED), so the/api/webhooks/[...path]forward threw before reaching the API. TheExpectheader is now dropped along with hop-by-hop headers — the 100-continue handshake is meaningless to replay on a proxied request.4. ADO comment webhooks failed schema validation
Real
ms.vss-code.git-pullrequest-comment-eventdeliveries carry the comment object directly asresource— even withresourceVersion: 1.0pinned on the subscription — not the documentedresource: { comment, pullRequest }nesting (confirmed against the raw delivery body in ADO's notification history). A new normalization step detects the flat shape, extracts repository + PR id fromresource._links, rehydrates the pull request via a newgetAdoPullRequesthelper, and hands the documented shape to the existing schema and handler unchanged.Validation
command-schema,source-control,ado api, webhook proxy route,normalizeCommentWebhook)pnpm lint:fast,pnpm check-types:fast,pnpm knipall passpullrequest.created/updateddeliveries return 200 and enqueue review tasks, review comments post back to the ADO PR thread,@roomotecomment mentions parse and route correctly, and PR completion status updates deliver cleanly🤖 Generated with Claude Code