Verify idempotency

[andreaTP]

This PR adds a job to compare the results of the two subsequent generations performed with Kiota

fixes #2442

[andreaTP]

For the records, the IT tests of this PR won't pass:

• the Java IT are broken due to "package jakarta.annotation does not exist" (should be easy to solve by changing the dependency
• the "idempotency" ITs are demonstrating the original issue

[baywet]

Thanks for the contribution as always! One minor comment. Also if you want to go ahead and add the missing java dependency, please do.

[sebastienlevert]

What a great contribution @andreaTP! Great idea to validate idempotency!

[baywet]

Hey @andreaTP
Thank you for the contribution as always and for your patience on this one. I wanted to take the time to RCA the differences and only got the time to do so now...
I've already fixed 3 trivial bugs. I still have to look at a lot of the failures.
A lot of them seem to be caused by #3067
Having a suppression mechanism based on what we have for the integration tests might be helpful to get this PR merged.
What do you think?

[andreaTP]

@baywet thanks for getting back as always!
I'm on PTO until the end of the week, so, if you need changes by me you would need to wait for next week.

I do believe that this subject (idempotency) is extremely important to have a healthy project, at the same time, it is, usually, really hard to keep it prioritized by PMs.
I would encourage any trick to keep it relevant at the eye of your BU.

I'm a bit skeptical at ignoring failures for this use-case as those tests are "designed to be unstable" unless all of the bugs have been solved.

Keeping the PR open (and rebasing after any meaningful change) or merge it keeping the tests failing are both strategies that would favor prioritization in my experience.

That said, I have little context about what is going on on your side and I openly let you take the final decision, I have no strong objections and I trust your final judge :-)

[baywet]

The reason I was mentioning that is because I don't want to hold merging this infrastructure improvement on fixing this bug we already know about #3067

Note for me for later: 22 failing before last force push

[baywet]

The last force push brought us down to 13 failures. I've implemented a couple of additional fixes which should bring us down to 9 failures. Here is the list of the last remaining 9 ones which all map to known issues. I'll implement a suppression mechanism next.

• php, apisguru::twitter.com:current IComposedTypeWrapper has naming issues #3067
• java, apisguru::stripe.com IComposedTypeWrapper has naming issues #3067
• typescript, https://developers.pipedrive.com/docs/api/v1/openapi.yaml composed types serialization support for TypeScript #1812
• typescript, apisguru::twitter.com:current composed types serialization support for TypeScript #1812
• php, apisguru::stripe.com IComposedTypeWrapper has naming issues #3067
• csharp, apisguru::stripe.com IComposedTypeWrapper has naming issues #3067
• typescript, apisguru::stripe.com composed types serialization support for TypeScript #1812
• ruby, apisguru::stripe.com composed types serialization support for Ruby #1816
• go, apisguru::stripe.com IComposedTypeWrapper has naming issues #3067

[baywet]

I think we should be good to merge this now. @andrueastman for final review

[andreaTP]

Thanks a lot @baywet for taking over this one 👍

[andrueastman]

👍🏼