gha: gate CI on org membership or ok-to-test label

[alicefr]

Execute the CI if the author is an org member or if the PR is labeled with the ok-to-test if we trust the author of the PR.

[HarshwardhanPatil07]

is this because we are going to use konflux? i don't see this pattern in bootc

[alicefr]

@HarshwardhanPatil07 no it is because I don't want always to manually approve the CI run for no-members. Like for example: #168 . We can discuss this on Monday. But it is a common label used by other orgs

[alicefr]

@Johan-Liebert1 do you know how the other repositories in bootc-dev org approve the CI run for PRs from no-org members?

[HarshwardhanPatil07]

they just run for every pr :) and if we want full test suite to be ran we run it through ci/merge i guess

[HarshwardhanPatil07]

i saw it when i was no-org mem

[HarshwardhanPatil07]

@Johan-Liebert1 can you confirm?

[Johan-Liebert1]

Hmm.. I don't remember ever approving workflows to run on bootc particularly (I might be wrong here though). I do remember permitting CI to run for bootupd (again, maybe). I don't remember which repo it was where I had to manually approve CI to run if PR wasn't opened by a non-member of the org.

[alicefr]

let's merge this, we can always revert it if we found a better way

[cgwalters]

This won't work as is, here's a quick result of a chat with Copilot, key bit is:

1. GitHub’s approval gate happens before the workflow starts.

Details

**No—not as written.** There are two separate issues:

1. GitHub’s approval gate happens before the workflow starts.
   If the PR author requires approval under the repository setting, GitHub will hold the workflow run. The check-permissions job cannot grant permission afterward, because it never runs. Adding ok-to-test will not bypass GitHub’s pre-run approval policy. GitHub evaluates the PR author and the actor who triggered the event before running fork workflows. GitHub documentation

2. The reusable-workflow path appears invalid.
   The PR adds:

   uses: $/.github/workflows/check-permissions.yml

   For a workflow in the same repository, this should be:

   uses: ./.github/workflows/check-permissions.yml

   The current $/.github/... path will likely cause workflow validation to fail.

With the setting “Require approval for first-time contributors”, GitHub will automatically run workflows for:

• organization members;
• repository collaborators;
• contributors who have previously had a commit or PR merged into the repository.

But a genuinely new external contributor’s workflow will remain awaiting approval, regardless of whether the PR has an ok-to-test label. GitHub explicitly warns that the first-time-contributor policy is based on repository history, not on a workflow-defined label. Repository Actions settings

So the workflow can gate jobs after GitHub has started the workflow, but it cannot replace GitHub’s approval mechanism.

Also, because the workflow listens for labeled, applying ok-to-test may create another run, but it still does not guarantee bypassing approval for a first-time external contributor: GitHub checks both the PR author and the actor that triggered the workflow.

At minimum, fix the path:

jobs:
  check-permissions:
    uses: ./.github/workflows/check-permissions.yml

If the goal is “new external PRs run only after a maintainer marks them trusted,” the reliable design is usually:

• use GitHub’s approval setting for the initial safety boundary;
• have a maintainer approve the workflow run, or
• use a trusted pull_request_target workflow to inspect the label and dispatch trusted CI carefully.

Be especially cautious with pull_request_target: it runs with the base repository’s privileges, so it must not execute untrusted PR code before the authorization check.