I have been able to run the Wheel builder event in my fork.

Note that the workflow_dispatch event must be in the default branch before we can manually trigger the workflow. Once this PR is merged to master, only collaborators with write access should be able to manually trigger the workflow on any branch (even on forks).

Is there a way to trigger workflow_dispatch on a pull request? It seems like it can only be triggered on a branch from the main repo.

Is there a way to trigger workflow_dispatch on a pull request? It seems like it can only be triggered on a branch from the main repo.

Yes, you can trigger on a branch from the forked repository. Indeed, I have been able to trigger the workflow_dispatch event on the alfaro96:trigger_workflow_dispatch branch.

Yes, I can see how a contributor can trigger the workflow on their fork. How does a reviewer trigger the workflow when they are reviewing a PR?

Yes, I can see how a contributor can trigger the workflow on their fork. How does a reviewer trigger the workflow when they are reviewing a PR?

What do you about having a cd build tag to trigger the Wheel builder?

What do you about having a cd build tag to trigger the Wheel builder?

The cd build tag allows maintainers to push directly to a branch to trigger the workflow. I am thinking of when we do a PR to a release branch and we want to make sure wheels build okay before merging. In this case, we would need to have the person that open the PR, navigate to through the github UI to trigger the workflow.

I think the workflow of manually triggering would be:

1. Create PR to branch and have the person that open that PR trigger the workflow on the branch and link it.
2. Merge branch.
3. Trigger workflow on branch from main repo
4. If wheels failed to build, open another PR to fix.

Sorry @thomasjpfan, I misunderstood you 😞.

Nevertheless, I think that I get your point now.

I think the workflow of manually triggering would be:

1. Create PR to branch and have the person that open that PR trigger the workflow on the branch and link it.

Alternatively, we could go to the Actions tabs of the fork to check if the workflow works (previously triggered by the person that open the PR).

2. Merge branch.
3. Trigger workflow on branch from main repo

Yes, a maintainer should manually trigger the workflow_dispatch event in the main repository. Alternatively, we could automatically trigger using the push event to release branches (but I am not sure if we want to trigger the Wheel builder workflow on all pushes to release branches).

4. If wheels failed to build, open another PR to fix.

Yes if it is related with the PR itself (and not with external issues).

Going back to your comment in #18801 (comment), the question is how a reviewer (in this case, maintainer with write access) could trigger the Wheel builder workflow in a PR?

Sorry @thomasjpfan, I misunderstood you 😞.

It's okay! These things happen! I will do better with structuring my questions. :)

Going back to your comment in #18801 (comment), the question is how a reviewer (in this case, maintainer with write access) could trigger the Wheel builder workflow in a PR?

Yes this was the original question. If there was a way, I would be +1 on this PR.

I have not found a way to allow reviewers (maintainers with write access) to trigger the Wheel builder workflow on their own on PRs.

Maybe @rth could help us.

I have not found a way to allow reviewers (maintainers with write access) to trigger the Wheel builder workflow on their own on PRs.

I would be in favor of re-introducing the [cd build] commit message trigger then (in addition to the Github UI trigger). WDYT?

Yes, I suggested this, but it's true that this use case might be problematic. It's probably possible to trigger it from upstream branches, but that's not the worflow we use. Sorry )

Easy review @ogrisel and @thomasjpfan?

In the end, I have only included the workflow_dispatch event.

Hum I should have edited the commit message to reflect what this PR actually does...