fix(server): OIDC config via secrets fails (#18269)

[BZValoche]

Closes #18269

Improper ordering of function calls in (*SettingsManager).GetSettings, which causes warnings related to OIDC secrets not being found.
The call to updateSettingsFromConfigMap was done before the SettingsManager secrets were set.

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).
• The title of the PR conforms to the Title of the PR
• I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
• I have signed off all my commits as required by DCO
• My build is green (troubleshooting builds).
• I have added a brief description of why this PR is necessary and/or what this PR solves.

[bunnyshell]

❌ Preview Environment deleted from Bunnyshell

Available commands (reply to this comment):

• 🚀 /bns:deploy to deploy the environment

[agaudreault]

Can you add a unit test to validate that this fixes the issue? :)

By looking at the code, it looks like it does!

[BZValoche]

Can you add a unit test to validate that this fixes the issue? :)

By looking at the code, it looks like it does!

Will do, I have to write a unit test which fails the older version, first ;)

[BZValoche]

Can you add a unit test to validate that this fixes the issue? :)
By looking at the code, it looks like it does!

Will do, I have to write a unit test which fails the older version, first ;)

After looking into it, I don't think it is possible to write a test for it, because it would imply rewriting the GetSettings function, and show that the secretRefs are not expanded if the secrets list is empty.
Which makes totally sense.

updateSettingsFromConfigMap calls a function which expects the secrets to be set, but the function which actually sets them is tupdateSettingsFromSecret.

Don't know how to test that.

GetSettings() returns an eventually consistent *ArcoCDSettings, this PR just removes the warnings.
The root cause is calling OIDCConfig which is not a simple getter, but also mutates the ArcoCDSettings object by calling ReplaceMapSecrets.

I don't know how to test, because in the end, the data structure has the expected data, so there is nothing "wrong", except for that warning message which disturbs people like me while trying to debug ArgoCD integration with an OIDC provider ;)

The warning is still needed if the referenced secret does not exist, though.

[agaudreault]

Yep, that is a fair comment! Thanks for looking into it nonetheless :) Feel free to open a refactor PR if you feel like it, but that is totally up to you!

[nitishfy]

From the issue, it looks like this issue exists in 3.2.6 too. I think we'll be required to cherry-pick this.

[argo-cd-cherry-pick-bot]

🍒 Cherry-pick PR created for 3.2: #26389