Fix GCP PodIdentity not considered with WorkloadIdentity

[juldrixx]

Provide a description of what has been changed

Checklist

• When introducing a new scaler, I agree with the scaling governance policy
• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added
• Changelog has been updated and is aligned with our changelog requirements
• A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on (repo) (if applicable)
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

#5011

Relates to #

[github-actions]

Thank you for your contribution! 🙏 We will review your PR as soon as possible.

While you are waiting, make sure to:

• Add an entry in our changelog in alphabetical order and link related issue
• Update the documentation, if needed
• Add unit & e2e tests for your changes
• GitHub checks are passing
• Is the DCO check failing? Here is how you can fix DCO issues

Learn more about:

• Our contribution guide

[JorTurFer]

Hello,
The changes look good, but there is a test failing because that function you have changed is covered by a test. You have to add expectedPodIdentity: kedav1alpha1.AuthPodIdentity{Provider: kedav1alpha1.PodIdentityProviderNone}, to the test cases where the expectdPodIdentity isn't set.
About how to cover this PR with a test for the future, there are 2 options actually:

• Adding a test case that executes ResolveAuthRefAndPodIdentity and validates the output in this file
• Covering it with e2e test, adding another test case to the secret-provider folder using podIdentity with a CRD, such as Argo Rollouts. You can do it mixing any podIdentity test (for example this) with the custom resource test (like this). Basically, you can use the workload definition from the second-one, with the ScaledObject + process from the first one

[sammaxwellxyz]

Hi @JorTurFer

given this is a fix, to merge this PR, is the extra e2e required or a nice to have?

@juldrixx are you still working on this? I may be able to fork and fix the failing test but wouldn't be able to add the e2e in the short term

Cheers both

[juldrixx]

Hi @JorTurFer

given this is a fix, to merge this PR, is the extra e2e required or a nice to have?

@juldrixx are you still working on this? I may be able to fork and fix the failing test but wouldn't be able to add the e2e in the short term

Cheers both

I'm currently rather busy, but I might have some time next week to look at the test part. But if you want to do it before then, no worries you can.

[JorTurFer]

given this is a fix, to merge this PR, is the extra e2e required or a nice to have?

Any kind of test is required for preventing regressions and in this case, I'd say that e2e test is the easiest way because that code it's quite coupled and there isn't any other test already done that you can use as base for having all the test setup ready, you'd need to prepare all the unit test setup, which probably requires more time than writing an e2e test (but it's not mandatory an e2e test)

[zroubalik]

Replaced by: #5255