…428)

The vouch-check workflow was closing PRs from NVIDIA org members because
the GITHUB_TOKEN lacks read:org scope, causing orgs.checkMembershipForUser
to return 404 for non-public members. The catch block silently swallowed
these as expected 'not found' responses.

Add an author_association check from the webhook payload as the primary
bypass. GitHub sets this field server-side (MEMBER, OWNER, COLLABORATOR)
regardless of membership visibility, with no extra token permissions
needed. The existing API calls are kept as fallbacks.

Fixes the false positive that closed #430.

Co-authored-by: John Myers <johntmyers@users.noreply.github.com>

…load (#444)

The webhook payload field context.payload.pull_request.author_association
is unreliable under pull_request_target events — it was absent or not
populated, causing the previous fix (#442) to still fail.

Switch to fetching author_association via pulls.get REST API, which only
needs pull-requests permission (already granted) and reliably returns
MEMBER for org members regardless of membership visibility.

Also removes the redundant orgs.checkMembershipForUser and
repos.checkCollaborator fallbacks, which suffered from the same
GITHUB_TOKEN permission limitation that started this bug.

Co-authored-by: John Myers <johntmyers@users.noreply.github.com>

…#418)

The trigger-wheel-publish job was downloading the wheel artifact onto a
persistent self-hosted runner just to glob the filenames. Since
download-artifact does not clean the destination directory, stale .whl
files from every previous run accumulated in release/ and were all sent
to GitLab as WHEEL_FILENAMES.

Confirmed on the runner: /home/ubuntu/actions-runner/_work/OpenShell/
OpenShell/release/ contained 120+ wheels spanning versions 0.0.5
through 0.0.10.

Fix: capture wheel filenames as a job output in build-python-wheels and
pass them directly to trigger-wheel-publish. The trigger job no longer
downloads the artifact at all — it only needs the filenames to construct
GitHub release asset URLs for GitLab/Kitmaker.

)

The GITHUB_TOKEN cannot determine org membership — it lacks read:org
scope and this is not configurable via the permissions block. Both
author_association and orgs.checkMembershipForUser return NONE/404 for
org members (even public ones) when called with the repo-scoped token.

Use an ORG_READ_TOKEN secret (fine-grained PAT with read:org) when
available, falling back to GITHUB_TOKEN. Also restores the
checkCollaborator fallback since the PAT can resolve that too.

Setup required: create a fine-grained PAT with Organization > Members >
Read permission, then add it as a repo secret named ORG_READ_TOKEN.

Co-authored-by: John Myers <johntmyers@users.noreply.github.com>

The ORG_READ_TOKEN (read:org PAT) was being used for all API calls,
including closing PRs and posting comments, which it lacks permissions
for. Split into two steps:

1. Org membership check — uses ORG_READ_TOKEN exclusively
2. VOUCHED.td check + close — uses default GITHUB_TOKEN (has repo write)

Step 2 is skipped entirely if step 1 confirms org membership.

Co-authored-by: John Myers <johntmyers@users.noreply.github.com>

… env var (#419)

#452)

The secrets context is not available in step-level if expressions in
GitHub Actions — only in with and env blocks. This caused the workflow
file to be invalid, failing every run with:

  Unrecognized named-value: 'secrets'

Fix by exporting the secret to a job-level env var and checking that
in the step condition instead.

Co-authored-by: John Myers <johntmyers@users.noreply.github.com>

…453)

#464)