eng, SDK automation for data-plane, fallback action when codegen fail

[weidongxu-microsoft]

Track the discussion whether we want to do the fallback below:

Source be TypeSpec and DPG. Condition be SDK automation fails on either emitter or compile.

We may want to check pre-condition, that tspconfig.yaml contains

partial-update: true

or the existence of

customization-class: ##

If condition meets, automation can do the fallback codegen logic

1. delete the code of the package in SDK repo
2. remove the line of customization-class in tspconfig.yaml Re-generate from the TypeSpec.

[github-actions[bot]]

@moarychan @netyyyy @rujche @saragluna

[github-actions[bot]]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[haolingdong-msft]

May I know the intension of validation? If we want to make sure we can generate SDK successfully when service requests to release SDK. Then we should have the same tsp-config.yaml for both validation and service team's release request. Otherwise, even validation passes, generation would still fail when service request to release SDK.

PS: I did a quick search, we have 12 services using customization-class and 22 services using partial-update.

[weidongxu-microsoft]

Eng may want to avoid the coupling, so the Validation on their PR only check the TypeSpec source, without taking customization into consideration.

The issue here is intended for discussion within Java devs. Though personally I didn't expect very strong opinion on the opposite. As:

1. currently we do factor customization in Validation,
2. and Validation can fail on it,
3. and service may (or may not) contact us to ask about the failure, we will typically reply if you do break, you need to handle SDK after the PR,
4. and they can merge PR despite of the failure.

If we do this fallback automatically, the only part we'd miss is (3) that service may not know the change breaks customization (we would print a warning, but I guess no one read the warning anyway).

[weidongxu-microsoft]

Dev had a concern that the fallback can produce an apiview that not valid for review (and service dev can miss the error/warning messages from Validation, especially now it is not piped to Github check).

Though we think this be a rare situation, and may for now proceed with the fallback logic.