Improve type extraction from resource hierarchy for ownerDetails

[fabian-heib]

What this PR does

Improve type extraction from resource hierarchy for ownerDetails

Replaced fixed index-based type assertions with a dynamic type check loop over the hierarchy slice. This enhances robustness by allowing flexible ordering and avoiding panics on unexpected slice lengths.

Updated error messages to clearly indicate missing types instead of reporting incorrect type assertions.

Why?

We have a case where the resource group is created within terraform so aso doesn't know it exists with objects. The armId exists and works but this breaks check which check's the amount of objects found. Change so it will check for the needed objects instead of checking a number.

Checklist

• this PR contains documentation
• this PR contains tests
• this PR contains YAML Samples
• this PR has been run

[fabian-heib]

@microsoft-github-policy-service agree company="Stakater"

[matthchr]

This change looks reasonable to me - have you tested it? Can you talk about how?

I don't think any of our existing tests cover this case, but the updated code looks correct to me.

Thanks for the PR!

[fabian-heib]

This change looks reasonable to me - have you tested it? Can you talk about how?

I don't think any of our existing tests cover this case, but the updated code looks correct to me.

Thanks for the PR!

I have not tested it, Im thinking for me it would be easier to add a specific test for this function instead of trying to run a build version of ASO, might have some time during this week or early next week

[matthchr]

Would love to see a test for this but absent that, we're releasing soon and this code looks right to me. I'm going to run the tests on this and merge it, it should get published as an experimental image and you can try that out with your scenario and confirm it works end to end. Assuming it does. great -- if not we're no worse than before.

We do have a test for the "standard" owner hierarchy so if that test fails we won't merge - but I don't expect it to fail.

[matthchr]

/ok-to-test sha=5a02ddb

[matthchr]

/ok-to-test sha=5a02ddb

[fabian-heib]

Would love to see a test for this but absent that, we're releasing soon and this code looks right to me. I'm going to run the tests on this and merge it, it should get published as an experimental image and you can try that out with your scenario and confirm it works end to end. Assuming it does. great -- if not we're no worse than before.

We do have a test for the "standard" owner hierarchy so if that test fails we won't merge - but I don't expect it to fail.

I still would like to add a test but can do it in a seperate PR.
Trying to setup a resolver seems impossible somehow. I tried writing a small test around the getOwnerDetails but can't seem to create a resolver at all, tried with the testcommon package but that creates a import cycle. Any tips on how to create test resolver? Or should I maybe move the test to other testing package?

[matthchr]

You can see an example of constructing a resolver here: v2/internal/resolver/resolver_test.go, as well as the one in testcommon that I believe you found already.

If you aren't able to write a test for this, that's OK - fully admit that it's not that easy to test this scenario currently. If you don't plan on adding one, can you open an issue for adding a test for this scenario and link to this PR, and I can add one sometime next week or the week after.

In the meantime going to merge this to make sure that it gets into the next release, as I believe the code is correct.