ci: add breaking change detector

[rluvaton]

Which issue does this PR close?

Partially closes:

• Automate breaking change detection #21406

Rationale for this change

detect breaking changes

What changes are included in this PR?

add new github workflow

Are these changes tested?

Looks like it is working

Are there any user-facing changes?

no

[rluvaton]

Added to here so I can test it

[rluvaton]

@alamb, @comphead , would love your review
once merge I will iterate over this, but this works from what I tested

[alamb]

Thanks @rluvaton -- I left some ideas

once merge I will iterate over this, but this works from what I tested

How did you test?

My biggest concern for all these CI jobs / improvements is the bandwidth to maintain them . We have such limited maintainer bandwidth in general.

Have you considered running this check on one of your own machines (rather than as a github action), polling for PRs to test? We have had good luck with that model and the run benchmark commands.

I think external runners are better because:

1. They are easier to debug
2. They are maintained outside of the normal DataFusion code repo
3. They aren't limited to the github workflow syntax / logic (which I find very hard to debug)

What do you think?

[alamb]

I am not sure how to debug scripts like this -- can you please put this logic into an existing script (like maybe ci/scripts/changed_packages.sh?

[rluvaton]

extracted along with creating comments

[alamb]

I think the github runner already has rust installed so this step is unecessary probably?

[alamb]

I thought in general the ASF CI jobs are supposed to avoid using non github actions (unless it is on the whitelist) -- so I am surprised this works.

[rluvaton]

did not test the sticky pull request itself, just tested the breaking change detector

[rluvaton]

Thanks @rluvaton -- I left some ideas

once merge I will iterate over this, but this works from what I tested

How did you test?

locally

My biggest concern for all these CI jobs / improvements is the bandwidth to maintain them . We have such limited maintainer bandwidth in general.

Usually ci workflows do not really change

Have you considered running this check on one of your own machines (rather than as a github action), polling for PRs to test? We have had good luck with that model and the run benchmark commands.

I don't have one

I think external runners are better because:

1. They are easier to debug
2. They are maintained outside of the normal DataFusion code repo
3. They aren't limited to the github workflow syntax / logic (which I find very hard to debug)

What do you think?

Unfortunately I don't have my own machines and maintaining a my own script which involves logic that already come built in inside github action sounds harder to maintain, and also I would need to manage my own machines, debug, etc rather than using existing github infra

[alamb]

My biggest concern for all these CI jobs / improvements is the bandwidth to maintain them . We have such limited maintainer bandwidth in general.

Usually ci workflows do not really change

Maybe that is true, but I have spent more hours of my life trying to debug / fix github workflows than I would like to admit.

Unfortunately I don't have my own machines and maintaining a my own script which involves logic that already come built in inside github action sounds harder to maintain, and also I would need to manage my own machines, debug, etc rather than using existing github infra

Yes it definitely shifts the maintenance burden (aka who pays for the maintenance)