Let's try this.

Now, it has been triggered 😉.

Thank you @ogrisel for bearing me!

The additional jobs make reading CI status a bit harder. There are now 25 CI tasks on master. Another alternative is to trigger this manually (via Github UI) prior to a release on some test branch and then run it on releases (see e.g. scikit-learn-contrib/scikit-learn-extra#74).

I don't think we would care much about wheels CI, short of the few weeks before the release, and those CI statuses even if they are skipped would just create noise for most contributors.

The additional jobs make reading CI status a bit harder. There are now 25 CI tasks on master. Another alternative is to trigger this manually (via Github UI) prior to a release on some test branch and then run it on releases (see e.g. scikit-learn-contrib/scikit-learn-extra#74).

I don't think we would care much about wheels CI, short of the few weeks before the release, and those CI statuses even if they are skipped would just create noise for most contributors.

+1 of using the workflow_dispatch event to trigger the Wheel builder workflow. Thus, we do not need the [cd build] commit marker and I think that we can even manually trigger the workflow in the branch of the fork (without needing to use a branch on the scikit-learn repository.

I will open a PR ASAP and we may evaluate there this proposal.