Adding a workflow_dispatch trigger for the GitHub Actions jobs makes it possible to run the GHA CI jobs for commits to branches in a fork without opening a "draft/WIP" PR to one of the main release branches. It also runs the SSL tests which normally get skipped for PRs.

The main constraint is that

* The main constraint is that the the `workflow_dispatch` trigger must be in the GHA workflow yaml files for the branch to be selectable as a target on the Actions tab when manually triggering a workflow. Having the change made to the main branch and backported would mean that new or rebased branches would have the trigger needed for manually running the CI job in forks.

Add Lukasz to get his opinion on this idea.

Another observation, first-time contributors need a maintainer to approve the workflows for their PRs -- from the looks of it that isn't an instant process and could take a few days, so this also gives first-time contributors a way to check their changes against the jobs that will run as part of the required CI checks.

> first-time contributors need a maintainer to approve the workflows for their PRs

This is an important security consideration, so I'd rather not go and change it.

On the main request, provided the workflow_dispatch is only triggerable by non-contributors in their own fork (without any of our tokens/etc.) then it's fine by me. If it allows anyone to trigger CI builds against the main repo, I'd rather not.

> On the main request, provided the workflow_dispatch is only triggerable by non-contributors in their own fork (without any of our tokens/etc.) then it's fine by me. If it allows anyone to trigger CI builds against the main repo, I'd rather not.

It should require write permissions in a repository to use the trigger, so they'll only be able to run workflows in the context of their fork: https://github.community/t/who-can-manually-trigger-a-workflow-using-workflow-dispatch/128592/4

I think you could also test this out by going to my fork and seeing if it lets you trigger the workflow: https://github.com/nightlark/cpython/actions/workflows/build.yml

> I think you could also test this out by going to my fork ...

Good point, and I can't trigger a build on your fork.

This seems okay to me.

> first-time contributors need a maintainer to approve the workflows for their PRs

How is manually dispatched workflows different from just opening a PR to your own fork? I do that from time to time in order to run the CI before opening a PR against the CPython repo.

> How is manually dispatched workflows different from just opening a PR to your own fork? I do that from time to time in order to run the CI before opening a PR against the CPython repo.

Here are a few thoughts on how it is different:
- They can be set up to take `inputs` that customize the behavior of the workflow run. Recently in another issue someone had asked about getting the Windows MSI installers from a CI build run but that workflow doesn't upload any artifacts; an input could be added that uploads the installers as artifacts in the cases they would useful while keeping the default behavior of not uploading artifacts for PRs, or an input could be added to enable additional debugging output/running extra tests to track down an issue
- Multiple builds of the same commit can be started; if there's a test that fails intermittently you could queue up 10 runs of a workflow and come back later to see if it is still happening from a larger sample size
- The jobs/workflows run can be more targeted; if you just want to build the docs part of a larger change set, you don't need to run the workflow for compiling + running tests. If all you care about is a generated installer, only that workflow needs to get run (less likely to hit the max concurrent builds for your account if you have workflows running in other non-cpython repositories)
- Temporary PRs don't need closing to keep subsequent commits from runnings jobs if you don't care about their results, or after the PR gets merged in the upstream CPython repo
- May be marginally faster to trigger a workflow run than opening a PR (in terms of slower loading pages/tabs on the GitHub website)

Neat! Thanks :)