#966 hard-coded `buildkitd-config: /etc/buildkit/buildkitd.toml` inside
the `driver: local` branch of the setup-buildx composite action. The only
caller using that driver is shadow-docker-build.yml, which runs inside
the ghcr.io/nvidia/openshell/ci:latest container — so the host-side
buildkitd.toml was invisible to docker/setup-buildx-action and every
matrix job failed at "Set up buildx".
Revert the hard-coded path and expose it as an opt-in input on the
action (empty default, passed through to both the remote and local
branches). Wire shadow-docker-build.yml to bind-mount /etc/buildkit
into the ci container and pass the path explicitly, so the action can
read the file from inside the container. Remote-driver callers are
unaffected (empty input is a no-op).
Signed-off-by: Jonas Toelke <jtoelke@nvidia.com>
Without a per-arch SCCACHE_GHA_VERSION, both matrix jobs
(linux-amd64-cpu8 and linux-arm64-cpu8) target the same GHA cache
key. Run 1 on 2026-04-24 showed this concretely: arm64 started
first and landed 575/1064 cache writes; amd64 started ~1 min later
and every one of its 1062 writes failed, leaving the cache with no
amd64 entries at all.
Partitioning by matrix.runner ensures each arch gets its own
cache namespace, letting us see real warm-cache behavior on the
subsequent Run 2-4 dispatches.
Signed-off-by: Jonas Toelke <jtoelke@nvidia.com>
- add a dedicated `test-gpu.yml` workflow for validating the new shared NVIDIA GPU runner infrastructure
- keep the existing branch E2E and branch checks workflows unchanged for now
- add the repository-side `copy-pr-bot` configuration required for workflows that run on NVIDIA hosted workers
Fork PRs receive a read-only GITHUB_TOKEN that cannot push to gh-pages,
causing the deploy step to fail with a 403. Skip the deploy for fork PRs
while still running the docs build to validate changes compile cleanly.
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>
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>
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 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 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>
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>
The 'Trigger Release Tag workflow' step uses gh workflow run to dispatch
release-tag.yml, which requires the actions:write permission. Without it
the GITHUB_TOKEN gets HTTP 403: Resource not accessible by integration.
Piotr Mlocek