fix: process ssh_url and http_url when receiving a webhook from GitLab #7657

[mrtati]

This is a quick fix for processing Gitlab webhooks when the ssh_url or http_url is different from the web_url and the automated matching fails in getWebUrlRegex().

E.g. Gitlab UI is reachable via subpath like mydomain.com/gitlab/group/repo but the ssh access is available as mydomain.com:2222/group/repo so the subpath /gitlab/ part is missing.

I've tested it locally and it now correctly triggers app sync when the webhook is received. Before the fix, the webhook was just ignored. Please note: While the webhook is logged 3 times, once for each URL, the app refresh is triggered only once.

Fixes: #7657

---

Note on DCO:

If the DCO action in the integration test fails, one or more of your commits are not signed off. Please click on the Details link next to the DCO action for instructions on how to resolve this.

Checklist:

• [X] Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
• [X] The title of the PR states what changed and the related issues number (used for the release note).
• [X] The title of the PR conforms to the Toolchain Guide
• [X] I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
• [ ] I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them.
• [ ] Does this PR require documentation updates?
• [ ] I've updated documentation as required by this PR.
• [ ] Optional. My organization is added to USERS.md.
• [X] I have signed off all my commits as required by DCO
• [X] I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
• [ ] My build is green (troubleshooting builds).
• [ ] My new feature complies with the feature status guidelines.
• [X] I have added a brief description of why this PR is necessary and/or what this PR solves.

Please see Contribution FAQs if you have questions about your pull-request.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 49.32%. Comparing base (f87897c) to head (fcc5f30). Report is 102 commits behind head on master.

:exclamation: Current head fcc5f30 differs from pull request most recent head d6a679d. Consider uploading reports for the commit d6a679d to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #14740      +/-   ##
==========================================
- Coverage   49.73%   49.32%   -0.42%     
==========================================
  Files         274      272       -2     
  Lines       48948    47979     -969     
==========================================
- Hits        24343    23664     -679     
+ Misses      22230    21973     -257     
+ Partials     2375     2342      -33     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[jimmyjones2]

I've had the same issue with gitea - can the same fix be applied to other SCMs as well?

[mrtati]

I've had the same issue with gitea - can the same fix be applied to other SCMs as well?

Sorry, I have not used Gitea ever. By browsing the docs, I think it sends the webhook in "Github" format: https://docs.gitea.com/next/usage/webhooks#event-information If so, then a similar patch can be implemented to the Github webhook processing part as there we have ssh_url and a clone_url (probably the same purpose as http_url for Gitlab).

I did not want to touch other parts, as I have no means to test it. Also, I am not sure what other implications would be if we changed the github processing part.

[ngnix]

Guys, is there any activity on this problem? On the latest version of Argocd there is still a problem with hooks if the repository was configured via ssh...