Skip to content

Add blindoracle plugin #37

Add blindoracle plugin

Add blindoracle plugin #37

Workflow file for this run

# §8.6 — the labeler. It runs on `pull_request_target` because a plain `pull_request`

Check warning on line 1 in .github/workflows/labeler.yml

View workflow run for this annotation

GitHub Actions / labeler

Workflow execution policy warning (evaluate mode)

On November 2, 2026, GitHub will restrict `pull_request_target` on public repositories by default. To continue allowing the event trigger, configure an Actions policy. Learn more: https://gh.io/securely-using-pull_request_target#default-policy-for-pull_request_target
# trigger gets a READ-ONLY token on fork PRs and cannot label them, which would leave every
# community PR unlabelled and therefore ungated.
#
# THIS IS THE ONE SAFE USE OF pull_request_target: it checks out NOTHING and runs NO
# repository code. It reads the PR author from the event payload and calls the labels API.
# Never add a checkout step to this file.
#
# Every incoming PR is a community submission (our own agents push directly to main, they do
# not open PRs), so this always applies `community` + `needs-verification`. A maintainer clears
# `needs-verification` once the entry is reviewed. (There is no "agent PR" fast-path — if one is
# ever wired to a real bot account, add the branch back here.)
name: labeler
on:
pull_request_target:
types: [opened, reopened]
permissions:
pull-requests: write
contents: read
jobs:
label:
runs-on: ubuntu-latest
steps:
- name: apply community labels
uses: actions/github-script@v7
with:
script: |
const author = context.payload.pull_request.user.login;
const labels = ['community', 'needs-verification'];
await github.rest.issues.addLabels({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.payload.pull_request.number,
labels,
});
core.info(`labelled ${author} PR: ${labels.join(', ')}`);