Move hash collision test to run only when merging to main

[Omega359]

Which issue does this PR close?

part of #13845

Rationale for this change

The hash collisions job is expensive (just as expensive as the cargo docs tests which are being worked on elsewhere) and rarely fail. It would be better to just run the hash collision job on merge to main instead of on every PR checkin.

What changes are included in this PR?

github actions updates.

Are these changes tested?

Well, kinda. I don't have a merge to main to actually test that portion however from reading the github documentation it should work.

Are there any user-facing changes?

No.

[alamb]

Thanks @Omega359 -- let's merge this to main and we can iterate / fix it as follow on PRs if needed.

[alamb]

The way we do it in arrow is

on:
  # always trigger
  push:
    branches:
      - main

https://github.com/apache/arrow-rs/blob/4a0bdde24f48d0fc1222d936493f798d9ea4789d/.github/workflows/arrow.yml#L25-L29

I'll make a small follow on PR to touch it up if necessary

[alamb]

Here is what appears to be the latest workflow: https://github.com/apache/datafusion/actions/runs/12587068377

It does not appear to be running the hash collisions test 🤔

Interestingly there is a separate action that seems to have run on your PR that ran the test:
https://github.com/apache/datafusion/actions/runs/12587068386

I think it would be better if the checks run on the commit on main so the test results end up attached to the commit.

I will make a new PR

[Omega359]

It wouldn't run in rust workflow as it's been removed from there. https://github.com/apache/datafusion/actions/runs/12587068386 is where it ran (new workflow).

[alamb]

It wouldn't run in rust workflow as it's been removed from there. https://github.com/apache/datafusion/actions/runs/12587068386 is where it ran (new workflow).

Yeah, what I am seeing from https://github.com/apache/datafusion/actions

is that the job ran on your brnach

So I don't think it gets reported attached to the commit on main:

[Omega359]

Hmm, yes, that is not what we desire here. We want a blocking check on the merge so on failure merge fails. Perhaps it should run on approval?

[alamb]

We want a blocking check on the merge so on failure merge fails. Perhaps it should run on approval?

That is a great idea

[alamb]

We want a blocking check on the merge so on failure merge fails. Perhaps it should run on approval?

That is a great idea

I thought about this some more. I think the key property is that we don't use a version of DataFusion where hash collisions fails. If we run the new job on approval I worry we will maybe not wait for it to complete prior to merge

Thus I would like to proceed with this PR

• Change trigger, rename hash_collision.yml to extended.yml and add comments #13988