Webhooks for Azure DevOps do not trigger gitjob when URLs don't match old format

[matteotumiati]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Here are two valid URLs pointing to the same resource:

1. https://dev.azure.com///_git/
2. https://.visualstudio.com//_git/

Both are valid and, according to Azure DevOps, interchangeable. The problem is that if I have set the first one in my GitRepo but Azure DevOps sends a webhook using the second format, then Fleet won't be able to recognize the URL and update the GitRepo.

Expected Behavior

There should be URL matching between the first and the second format because both are valid and supported by Azure DevOps.

Steps To Reproduce

1. Create a GitRepo with disablePolling: true and without pollingInterval
2. Enable webhooks with the ingress in Rancher
3. Set the URL of the GitRepo to https://dev.azure.com/org/project/_git/repo
4. Disable the "Use the new URL" toggle in organization settings in the Azure DevOps org
5. Enable service hooks in Azure DevOps to point to the URL configured in Rancher on push against main branch for that URL
6. Enable debug logging for Fleet (I set debug: true, level: 5)
7. Commit a change to the repository in Azure DevOps
8. Observe how in the logs the payload is printed but the commit ID doesn't change and there are no jobs being created to sync the state

Environment

- Architecture: amd64
- Fleet Version: Tested with several versions of fleet above 0.12
- Cluster:
  - Provider: AKS
  - Options: 3 
  - Kubernetes Version: 1.31

Logs

Anything else?

No response

[weyfonk]

Pull request content for Rancher QA verification.

Additional QA

Problem

Fleet would not be able to process webhook calls for repos using the legacy URL for Azure DevOps (<name>.visualstudio.com), because event payloads would contain the newer URL equivalent (dev.azure.com) instead.

Solution

Fleet now maps legacy URLs to their newer equivalent when processing webhook calls from Azure DevOps.

Testing

Engineering Testing

Manual Testing

N/A

Automated Testing

Added unit tests validating that, when receiving an event payload for a repo created using a legacy Azure DevOps URL, Fleet is able to process the call and update the GitRepo accordingly.

QA Testing Considerations

Is the added unit test case realistic? In other words, would the payload of a webhook call for a repo using a legacy URL contain the newer URL only?

See reproduction steps above, replacing step 8 with expectation of success, e.g.:

Observe how in the logs the payload is printed but the commit ID doesn't change and there are no jobs being created to sync the state and the commit SHA is updated on the GitRepo, with a git job being created to update bundles.

Regressions Considerations

This should still work with repositories using the more recent Azure DevOps URL format (dev.azure.com).

[mmartin24]

Verified in Rancher v2.13-87dc022d05f8f22ee730e58b7a6ed108bd17ef4c-head with Fleet 0.14.0-alpha.4

---

Following steps above, after setting "Use the new URL" toggle off and enabling the webhook against https://fleetqa@dev.azure.com/fleetqateam/fleet-qa-examples/_git/fleet-private-repo-webhook, I pushed a commit, and it was correctly picked up and hash updated. I recorded a video to better show the process live:

Screencast.from.2025-10-10.13-28-49.webm

Leaving also screenshots:

Working correctly, closing issue.