NVIDIA-NeMo / NVIDIA-NeMo/Guardrails

ci: run a token-free Fern docs check on fork pull requests

Open
#2,367 0 comments 0 reactions 1 assignee View on GitHub

@yixinh-nv is already working on this.

Since Sep 8, 2026.

enhancement status: triaged
Dominant language
Python
Stars
7.2k
Forks
842
Avg merge
3d 1h
Merged PRs (30d)
25

Description

Did you check the docs?
  • I have read all the NeMo-Guardrails docs
Is your feature request related to a problem? Please describe.

The Check Fern docs job (.github/workflows/docs-build.yaml) runs make docs-fern-strict, which first regenerates the Python SDK reference through Fern's cloud and therefore needs DOCS_FERN_TOKEN. Pull requests from forks never receive repository secrets, so the job fails on every fork PR before it validates a single docs page (for example #2334 and #2366). Contributors get a red check they cannot fix, and reviewers lose the docs validation signal on exactly the PRs that most need it.

Describe the solution you'd like
  • Add a docs-fern-check Make target that runs fern check without regenerating the SDK reference.
  • In build-docs, restore the .fern-cache/fern-ref-sdk cache (same key preview-docs already uses) so the post-checkout hook never has to generate on a cache miss, then run docs-fern-strict when FERN_TOKEN is present and fall back to docs-fern-check when it is empty.
  • Keep the token-bearing path unchanged for same-repo PRs and pushes to develop.
Describe alternatives you've considered
  • Skipping the job entirely on fork PRs: loses docs validation for external contributions.
  • pull_request_target to get the secret: exposes the token to untrusted PR code; rejected.
  • Leaving it as is: the check is not required, but a permanently red job on fork PRs is noise that hides real docs breakage.
Additional context

Split out of #2366 at CodeRabbit's out-of-scope note; the change was verified there (the job went green on a fork PR with the fallback in place).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.