Dynamic matrix filtering for sample build workflows — any known reasons for the current broad recompilation and unit test triggering?

I've been looking at the CI/CD pipelines and noticed that the sample build workflows (e.g. samples-spring.yaml, samples-kotlin-server-jdk17.yaml, etc.) currently trigger a full matrix rebuild of all samples in a group whenever any file in that group changes.

For example, changing a single file in samples/server/petstore/springboot-sort-validation/ causes all ~37 Spring samples to rebuild, even though the other 36 are untouched.

I'd like to propose a change that uses git diff to compute a filtered matrix at runtime, so only the actually-changed sample(s) are built. I have a WIP implementation at #23964.

Also the unit tests always run even if the changes are scoped to just e.g. samples recompilation or addition of a new config without touching the actual implementation or the tests

Before marking the PR permanently as ready-for-review, I wanted to check: is there a deliberate reason for the current broad recompilation behaviour? Some possibilities I could imagine:

• Do you rely on the full rebuild as a cross-sample regression check (i.e. "a generator change regenerates all samples, so all should still compile")?
• Is there a concern that samples share dependencies or generated code in a way that makes isolated builds unreliable?
• Was the broad triggering simply the path of least resistance when the workflows were first written?

If the broad rebuild is intentional for correctness reasons, I'll close the PR. Or we can discuss whether there is some middle ground that would make sense

Thanks for the great project!

Start with the sample workflow files named in the issue, including samples-spring.yaml and samples-kotlin-server-jdk17.yaml, then review WIP implementation #23964. Compare the current matrix and unit-test triggers with the proposed filtering; done requires a maintainer decision on whether broad rebuilding is intentional or whether the narrower behavior should proceed.