Decide on process for external contributors to be able to trigger the CI

[jaredkhan]

The DVC status check requires use of secrets in the repo.
This means when external contributors open a PR, this causes some troubles, since they of course by default can't access these secrets.
We just need to decide what we want to do in that scenario.

[hyanwong]

So it sounds like the CI is not run using the main OneZoom account, but under the user who makes the PR, right? I'm assuming enabling access to the secrets might open them up to the PR user in general?

[hyanwong]

Copilot says:

the standard solution is to split trusted and untrusted execution paths so fork PR code never gets your long‑lived secrets.

== Recommended pattern ==

Run normal CI on pull_request (no secrets needed).
Run secret-using DVC checks on pull_request_target, but:

• checkout the base repo commit (trusted), not fork HEAD by default
• or require maintainer approval/label before checking out fork code
  Prefer short-lived cloud credentials via OIDC instead of static DVC_ACCESS_KEY_ID / DVC_SECRET_ACCESS_KEY.

== Safe workflow structure ==

A) Keep existing PR checks unprivileged

Your current Tests workflow stays on pull_request, but skip DVC when secrets unavailable.

B) Add a separate trusted workflow for DVC

.github/workflows/dvc-pr-target.yml
name: DVC (trusted)

on:
pull_request_target:
types: [opened, synchronize, reopened, labeled]

Critical security notes

Do not run fork PR code with secrets automatically.
With pull_request_target, never blindly checkout github.event.pull_request.head.sha unless you have a trust gate (label/approval and reviewer discipline).
Use least-privilege creds (read-only to needed DVC bucket/path).
OIDC + short-lived role is safer than static secrets.

(If you want, I can draft the exact minimal diff for your current .github/workflows/tests.yml + a new dvc-pr-target.yml tailored to OneZoom/tree-build.)