Refine the trigger of net-core-ci

[live1206]

Library name

N/A

Please describe the feature.

Right now, any change in ./eng apart from the excludes will trigger net-core-ci, which takes quite a while to finish.

azure-sdk-for-net/sdk/core/ci.yml

Line 12 in 06a44e3

- eng/

azure-sdk-for-net/sdk/core/ci.yml

Line 28 in 06a44e3

- eng/

azure-sdk-for-net/sdk/core/ci.yml

Lines 13 to 15 in 06a44e3

	exclude:
	- eng/mgmt/
	- eng/common/

Is it possible to narrow down the trigger further to avoid unnecessary ci runs?

During #45617, I exclude the newly added ./eng/pacakges to avoid later unnecessary net-core-ci trigger.

[live1206]

And also, net-core-ci was not triggered during #45605, which did break net-core-ci, filed #45806 for it.
We should add PR trigger of sdk/identity for net-core-ci.

[jsquire]

@live1206: The intent for this is to ensure that no change to the engineering system causes a regression that breaks SDK builds. The Core pipeline runs Azure.Core as well as a representative sample of other SDKs. We do not want to lose this validation, as it is an essential one to avoid repository-wide breaks.

Since the pipelines do run code generation in order to do API differences, I'm not sure that I agree we can safely make Azure plugin changes and not potentially break the entire repository. Unless I'm missing something, I don't think we'll want to exclude that.

//cc: @m-nash, @annelo-msft

[annelo-msft]

I don't have a good sense of the intended process around updates to the Azure plugin yet -- I feel like it would be good to evaluate that request in light of that. For example, when changes to the Azure plugin go in, will they regenerate all relevant Azure clients in the repo as part of the same change? Do we have the intended steps in that process written down somewhere that we could reference?

[live1206]

And also, net-core-ci was not triggered during #45605, which did break net-core-ci, filed #45806 for it. We should add PR trigger of sdk/identity for net-core-ci.

@jsquire @annelo-msft Shall we at least fix this firstly?

[live1206]

@live1206: The intent for this is to ensure that no change to the engineering system causes a regression that breaks SDK builds. The Core pipeline runs Azure.Core as well as a representative sample of other SDKs. We do not want to lose this validation, as it is an essential one to avoid repository-wide breaks.

Since the pipelines do run code generation in order to do API differences, I'm not sure that I agree we can safely make Azure plugin changes and not potentially break the entire repository. Unless I'm missing something, I don't think we'll want to exclude that.

Given Azure plugin isn't generating any SDK for now, can we skip Azure plugin during the implementation progress for now? It will save us quite some time to skip net-core-ci check during the PRs, which will be many in the coming months. We will reconsider adding it back or not when we enable SDK generation for it.

I don't have a good sense of the intended process around updates to the Azure plugin yet -- I feel like it would be good to evaluate that request in light of that. For example, when changes to the Azure plugin go in, will they regenerate all relevant Azure clients in the repo as part of the same change? Do we have the intended steps in that process written down somewhere that we could reference?

I agree we should think about the process thoroughly, in my mind it still follows the process of autorest.chsarp, that we need to re-generate all SDKs while we update the generator. I don't have a good answer for it at the current stage, might have better understanding during the implementation. And for sure, we should get this settled when Azure plugin is set to generate SDKs.

[jsquire]

Given Azure plugin isn't generating any SDK for now, can we skip Azure plugin during the implementation progress for now? It will save us quite some time to skip net-core-ci check during the PRs, which will be many in the coming months. We will reconsider adding it back or not when we enable SDK generation for it.

No objection to a short-term work-around for implementation - so long as this doesn't bypass validation when we start using the plugin for real-world generation in the repo. Let's please have an issue tracking reenabling it and figure out how to keep visibility there so that we don't overlook it.

[live1206]

Given Azure plugin isn't generating any SDK for now, can we skip Azure plugin during the implementation progress for now? It will save us quite some time to skip net-core-ci check during the PRs, which will be many in the coming months. We will reconsider adding it back or not when we enable SDK generation for it.

No objection to a short-term work-around for implementation - so long as this doesn't bypass validation when we start using the plugin for real-world generation in the repo. Let's please have an issue tracking reenabling it and figure out how to keep visibility there so that we don't overlook it.

Created #45825 for tracking to re-enable it.