ci: pass --branch through env and quote it

[kobihikri]

Hi, and thanks for supervision.

In .github/workflows/build-package.yml, the branch name is passed to the README script by interpolation, unquoted:

run: |
  python .github/scripts/augment_links.py README.md --branch ${{ github.head_ref || github.ref_name }}
  cat README.md

Actions expands ${{ ... }} into the script text before bash runs, so the branch name becomes part of the command rather than an argument to the script. Git allows $, (, ), backticks and spaces in branch names, and $(...) runs inside double quotes — and being unquoted here, a name containing a space would also split into two arguments, so augment_links.py would receive a truncated --branch value.

Scope, honestly: this is a reusable workflow_call workflow, and where it is called from pull_request a fork PR has a read-only token and no secrets. I am raising it as hardening and argument-robustness rather than as a live exploit.

The change passes the value through env: and quotes it:

env:
  BRANCH_REF: ${{ github.head_ref || github.ref_name }}
run: |
  python .github/scripts/augment_links.py README.md --branch "$BRANCH_REF"
  cat README.md

The || fallback is preserved by keeping the whole expression in the env: value, so the script receives the same branch string it does today, and cat README.md is untouched.

Disclosure: I used AI assistance to help spot this and prepare the change, and I read the workflow myself.

[CLAassistant]

All committers have signed the CLA.

[Borda]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

@kobihikri ^^ 🦝

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88%. Comparing base (c1d7b90) to head (2e2d92b).

Additional details and impacted files

@@           Coverage Diff           @@
##           develop   #2461   +/-   ##
=======================================
  Coverage       88%     88%           
=======================================
  Files           85      85           
  Lines        12143   12143           
=======================================
  Hits         10666   10666           
  Misses        1477    1477           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

This PR hardens the reusable workflow_call GitHub Actions workflow by ensuring the branch name is passed to the README augmentation script as a properly quoted runtime argument, rather than being interpolated into the shell command text.

Changes:

• Move ${{ github.head_ref || github.ref_name }} into a step-level environment variable (BRANCH_REF).
• Quote the branch argument in the augment_links.py invocation to avoid shell word-splitting and prevent branch-name characters from being interpreted by the shell.

[Borda]

@kobihikri, could you pls check the failing CI checks?

[Borda]

That would prevent checking any forked PRs, so we couldn't accept them...

[khassis-ops]

Sorry for the slow reply. I had a look, and I think those failures were older than this PR — and they're green now.

All three failing checks were the same job (build / build) pulled in by the publish workflows, and the failing step was 🔗 Link Checker:

[404] https://github.com/roboflow/supervision/blob/ci/branch-ref-via-env/.github/CONTRIBUTING.md
[404] https://github.com/roboflow/supervision/tree/ci/branch-ref-via-env/examples
##[error]Process completed with exit code 2.

augment_links.py rewrites the README's relative links to github.com/roboflow/supervision/<blob|tree>/$BRANCH/.... On a pull request from a fork, $BRANCH is the fork's branch name, which doesn't exist in this repository — so both links 404 and lychee (fail: true) exits 2.

It wasn't the quoting change. I ran the script against a clone of develop twice, once the way develop does it today and once the way this PR does it:

ae98d6820a3f9cf9c6b94fb0c4e91a6d1026c915b2f7e2ef4449aee1e80cbb6a  README (unquoted)
ae98d6820a3f9cf9c6b94fb0c4e91a6d1026c915b2f7e2ef4449aee1e80cbb6a  README (env + quoted)

Byte-identical, so the link check sees the same file either way. These three workflows only run here at all because their paths: filter names build-package.yml, which is the file this PR edits — that's why no other fork PR trips it.

The guard already exists in this repo. In 0dc9188 you added the link-check input to build-package.yml and wired it into ci-tests.yml:22:

link-check: ${{ github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository }}

publish-release.yml, publish-pre-release.yml and publish-testpypi.yml call build-package.yml with no with: block, so link-check falls back to its default: true. That was the whole difference: Build this Package / build (from ci-tests.yml) passed while build / build from the publish workflows failed.

So I pushed one commit, 2e2d92b1, that copies your expression to those three callers — same line, same comment, nothing else, +3 lines each. prettier --print-width=120 and actionlint are clean on all three. Someone approved the queued runs since, and all 39 check-runs on that commit now report success.

One thing I'd rather you decided than me: it widens this PR past the single quoting change you originally looked at. If you'd sooner keep this one narrow, say the word and I'll move the guard into its own PR and reset this branch.

(Disclosure: I use AI tooling to help me read code at this scale. The reproduction, the job log, and the commit are mine, and I've checked them.)