Revision redirection can affect not intended repositories

[archi144]

Hello.
Thank you for the tool! I've got a good time making my pipeline from ❌ to ✔️ to see the result worth it.
I want to share my feedback with you and I hope it'll help someone one day.

During the run I had an issue with resolving git revision:

Failed to generate applications from ApplicationSet error="failed to run argocd appset generate: argocd command failed: {\"level\":\"fatal\",\"msg\":\"rpc error: code = Internal desc = unable to resolve git revision : unable to resolve 'refs/pull/1474/merge' to a commit SHA\",\"time\":\"2025-07-22T14:54:07Z\"}\n: exit status 20" (AppSet: "my-app [rendered-apps-from-pr.yaml]") (branch: refs/pull/1474/merge)

In our Applications we use 2 repositories as sources: argocd and argocd-apps (org is omitted for brevity) .
Following the guide for GitHub Actions, I set REPO=${{ github.repository }}, which resolved into argocd as it should, according to the official doc.
Eventually, with the help of debug logs, I found out that redirecting revisions step was patching revisions in Applications from argocd-apps with value from TARGET_BRANCH env, which led to the failed revision resolving on ArgoCD's site - as such revision didn't exist in argocd-apps but did exist in argocd. Changing the REPO to argocd.git solved the case.
As I understand, containsIgnoreCase() function, decides whether App's revision should be patched.

My question is: should we keep comparing repoUrl with repo via strings.Contains() or we can use the full match? Or we can just warn users about partial match and recommend using full name of the repo with .git suffix, if that's applicable.

[dag-andersen]

@archi144
I’m glad you enjoy the tool! 🚀

Sorry for the late answer - I was on vacation last week :)

My question is: should we keep comparing repoUrl with repo via strings.Contains() or we can use the full match? Or we can just warn users about partial match and recommend using full name of the repo with .git suffix, if that's applicable.

This is a good question.

I understand the problem. Your case is special because one of your repos is a substring of the other.

As I understand, containsIgnoreCase() function, decides whether App's revision should be patched.

Correct - The reason it’s using contains is because I want to make sure we catch cases where the user has defined the Git URL with or without the .git suffix. That part is optional, so I’d prefer not forcing users to worry about it when using the tool.

Additionally, a few others have requested that the --repo URL be allowed as a substring of the full URL, because the full URL is sometimes templated. There was an GitHub issue about it, but I can’t find it right now. Here’s a simple example though: #90

So we either need to keep the contains functionality, or introduce a separate --repo-regex parameter that uses regex or something similar to find an exact match with the URL (I believe that would solve your case)

[archi144]

I was on vacation last week :)

I'm glad you could make time for yourself, it's as important as breathing.

Thank you for the explaining the history of using contains.

or introduce a separate --repo-regex parameter that uses regex or something similar to find an exact match with the URL

I believe there is no need for the --repo-regex parameter right now. But if someone occasionally bumps into the same issue, maybe a little warning in doc on the internals of --repo will save a soul or two.