Workflows get stuck on forks

[jsoref]

Forking is a standard practice in GitHub. When I fork this repository or pull in new versions of the default branch, workflows start running.

Quite a few of these workflows will sit there stalled for days because they're configured to use large runners.

It's really a pretty lousy experience as I'm trying to determine how things work and what I get are a bunch of things that don't work.

Things that could be done:

1. Use a job to define runners for jobs that might run on large runners.
   1. Have that job determine if the current repository has large runners and either pick that as an output or if not cause those jobs to run on a basic runner or not run at all.
2. Decide that certain jobs shouldn't run unless a var is defined (and define that for this repository and specific forks where people are willing to pay for large runners).

[aibaars]

I assume the problem you are running into are failure like this https://github.com/aibaars/codeql/actions/runs/7701893302 for jobs running on the main branch of your fork. I can see this is indeed a little annoying, although I had never noticed it myself.

@criemen and @adityasharad Perhaps we should add some if conditions on the workflows that can't run on a fork.

[angelapwen]

@criemen and @adityasharad Perhaps we should add some if conditions on the workflows that can't run on a fork.

We recently added something similar for a specific workflow in the CodeQL Action. It's done programmatically but the GitHub context variable should be ~similar: https://github.com/github/codeql-action/blob/eab49d76a36ac164bf08006f3efdba5c4c9c328c/src/init-action-post-helper.ts#L207

[jsoref]

The nice thing about the var is that if someone really wants to pay for large runners and set them up, they can.

It's good to be able to actually test things in forks before making PRs...