fix: parsed url is not exposed (#11816)

[alexef]

follow up on: #11819 according to @RomanBats
fixes: #11816
fixes: #11922

Now the code of revisionURL is consistent with repoURL above it. not anymore after subtler fix

Signed-off-by: Alex Eftimie alex.eftimie@getyourguide.com

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:

• 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.
• The title of the PR states what changed and the related issues number (used for the release note).
• 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.
• I have signed off all my commits as required by DCO
• 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).

[codecov]

Codecov Report

Base: 47.29% // Head: 47.29% // No change to project coverage 👍

Coverage data is based on head (2632d95) compared to base (abf6d73).
Patch has no changes to coverable lines.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #11916   +/-   ##
=======================================
  Coverage   47.29%   47.29%           
=======================================
  Files         245      245           
  Lines       41665    41665           
=======================================
  Hits        19706    19706           
  Misses      19974    19974           
  Partials     1985     1985           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[woehrl01]

@alexef

I suggest a more subtle fix like this, as it won't hide possible future unrelated errors on other method calls:

let parsed;
try {
    parsed = GitUrlParse(url);
} catch {
    // URL Parsing failed
    return null;
}

[crenshaw-dev]

@alexef could I trouble you for some unit tests on this function? :-)

[crenshaw-dev]

Also, am I correct to only cherry-pick this to 2.6?

[alexef]

@crenshaw-dev yes, this is 2.6 only. I'll add the unit tests

[alexef]

@crenshaw-dev nevermind, the tests already exists: https://github.com/argoproj/argo-cd/blob/master/ui/src/app/shared/components/urls.test.ts#L7

now the question is why they didn't fail when the previous change was introduced that changed the scope of const parsed?

[crenshaw-dev]

@alexef good question... I'll leave that as an exercise for later, since this fixes an important issue. :-)

[crenshaw-dev]

Cherry-picked onto release-2.6 for 2.6.0-rc3.

[jannfis]

@alexef May I ask why you set the breaking/high label on this bug? Is it by mistake, or is this a breaking change?

[alexef]

@jannfis the UI was completely broken (unable to view application details, presented stacktrace, no workaround) in master and in the 2.6 branch until rc3. If this doesn't grant a breaking/high I'm happy to remove it - also from related PR/issues, there were a few around this same story.

[jannfis]

@alexef Ah. Just as a heads-up for the future, the breaking/* labels indicate that a given change itself is breaking (e.g. is not backwards-compatible). For classifying bugs' severity, you can use the severity/* labels.