feat(gitprovider): Extend azure gitprovider supported urls

[b3go]

Refactored the gitprovider for azure so self hosted server urls also work.

[netlify]

✅ Deploy Preview for docs-kargo-io ready!

Name	Link
🔨 Latest commit	81b2d56
🔍 Latest deploy log	https://app.netlify.com/projects/docs-kargo-io/deploys/685a5e9d9752c50008adb7e8
😎 Deploy Preview	https://deploy-preview-4292.docs.kargo.io
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[hiddeco]

Can you please sign off on your commit? This is a requirement for us to be able to merge it. For instructions on how to do this, please see: https://github.com/akuity/kargo/pull/4292/checks?check_run_id=43187750239

[b3go]

Hey guys, thanks for looking into it. I will incorporate your feedback as soon as I am back from vacation!

I am actually not very happy about the hostname/provider name logic to step into the self hosted url validation but couldn't make anything better up, without a bigger refactoring. If you have any ideas let me know. I will gladly change it.

[krancour]

@b3go unless I am missing something, it seems this only makes the predicate work for self-hosted Azure devops, but nothing appears to be adjusting the client connection URL for self-hosted. It appears it will still, unconditionally, be of the form https://dev.azure.com/org/<project>/_git/<repo>.

[b3go]

@krancour true, the path is the same on self hosted and cloud services. For older instances, which where upgraded from when it was still called team foundation server there seems to sometimes be a base route /tfs, which would be the only difference to the cloud service urls.

On the self hosted server org is called collection but that's about it. API is the same

[krancour]

the path is the same on self hosted and cloud services

But hostname/domain is not.

[b3go]

the path is the same on self hosted and cloud services

But hostname/domain is not.

I probably misunderstood what you wanted to tell me then, sorry.

I thought about putting the call to parseSelfHostedRepoUrl at the end of the parseRepoUrl method, without the if. That would allow any url to be accepted and wouldn't enforce users to host their server with azure somewhere in the hostname. That would be more flexible but I am unsure if it could be problematic.

[krancour]

@b3go you've updated how org, project, and repo name are extracted from a repo URL, but look at how those results are being used:

https://github.com/akuity/kargo/pull/4292/files#diff-c2a6f499400ce5b01e38e813062669873d033b1da374ce5b17e6dcdbb07227e4R66-R78

No matter what self-hosted URL you give it, the base URL of the API that the provider will connect to is always be https://dev.azure.com/<org> and that obviously doesn't look like the correct base URL for your self-hosted Azure DevOps' API server.

Apart from this, you also have not updated the predicate:

https://github.com/akuity/kargo/pull/4292/files#diff-c2a6f499400ce5b01e38e813062669873d033b1da374ce5b17e6dcdbb07227e4R32-R38

Without updating the predicate, this provider will never be applied for URLs like this one: https://azure-devops.example.com/<collection>/<project>/_git/<repo>

[b3go]

Well looks like I was pretty naive at that. Should have given it more thought. Thanks for getting me on the right track. I will fix my PR when I am back!

[b3go]

This bothered me the whole vacation, usually I don't deliver such botched work. I haven't tested it yet but I incorporated the feedback, fixed the provider connection url and signed of the commits

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 52.95%. Comparing base (5f4832a) to head (ec7ebac).
Report is 93 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4292      +/-   ##
==========================================
- Coverage   53.02%   52.95%   -0.08%     
==========================================
  Files         330      354      +24     
  Lines       29488    31409    +1921     
==========================================
+ Hits        15637    16633     +996     
- Misses      13040    13929     +889     
- Partials      811      847      +36     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[b3go]

Unfortunately I am currently unable to test this in my environment. My company has installed a major update for the corporate proxy and now the container images can't build as a lot of downloads get blocked. Don't know when this will be fixed.

But something else: the codecov check fails because the coverage decreases by 0,08% even though it shows 100% coverage for my patch. Any ideas where I can have a look to fix this?

[krancour]

But something else: the codecov check fails because the coverage decreases by 0,08% even though it shows 100% coverage for my patch. Any ideas where I can have a look to fix this?

That won't block the PR from being merged.

[b3go]

I was finally able to test this in my local environment. It won't work unfortunately. I have outlined the reason in this Discussion: #4598

The open-pr promotion step needs to clone the git repository, on Azure DevOps Server this currently only works with user:pw and not PAT. The gitprovider uses this go repo for accessing the Azure Devops Api to create PRs: here. This can only open connections using PATs. So either Kargo won't be able to clone the repo, or create the pr.

As I've stated in the discussion the only way to make this work is to pass the http.extraheader in git clone/push. I would be happy to contribute to that but need some feedback where to start.