ci: skip the client docs deploy step on pull requests from forks

[Tespera]

This is a ...

• New feature
• Improvement
• Bug fix
• Others

Motivation

Every pull request from a fork that touches packages/core/client/** gets a red Build check from the Deploy client docs workflow, even though nothing in the PR is broken.

Both docs builds succeed; only the last step fails:

Build zh-CN            ✓
Build en-US            ✓
copy files via ssh     ✗   Error: can't connect without a private SSH key or password

The step uses secrets.CN_CLIENT_HOST / CN_CLIENT_KEY / … to upload the built docs to the preview server. GitHub does not expose repository secrets to pull_request runs whose head is a fork (this is a platform rule to keep secrets away from untrusted workflow changes), so the inputs are empty and appleboy/scp-action aborts before connecting. There is no configuration on the repository side that can change this.

The workflow's own run history shows the split: pull_request runs from internal nocobase/nocobase branches (e.g. #10074, #10092, #10494) succeed, while every run from a fork fails the same way (e.g. #10431, #10488). The failure is not visible to maintainers working from internal branches, which is probably why it has stayed.

Consequences for external contributors: the PR shows an overall failing status that has nothing to do with the change, and the reviewer has to open the job to find out that only the deploy step failed.

Description

Adds an if to the copy files via ssh step so that it runs only when secrets can actually be present:

if: github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository

• push to main: unchanged, deploys as before.
• pull_request from a branch in nocobase/nocobase: unchanged, deploys the pr-<n> preview as before.
• pull_request from a fork: the docs are still built (so a broken docs build is still caught), the deploy step is reported as skipped instead of failed, and the check goes green.

Nothing is lost for fork PRs: the preview has never been produced for them, since this step has never succeeded on a fork.

A note for maintainers: if a docs preview for fork PRs is wanted, the usual safe pattern is to split the workflow — build and upload an artifact on pull_request (no secrets needed), then deploy from a separate workflow_run job that runs with the repository's identity and never executes contributor code. That is a bigger change to your deploy setup, so this PR only makes the current behaviour honest and leaves that decision to you.

Verified: the YAML parses; the expression is the standard fork check used in GitHub's own docs. Because workflow definitions are taken from the base branch, existing PRs (including #10488) will only pick this up on their next push after merge.

Related issues

Observed on #10488 and #10431.

Showcase

Changelog

Language	Changelog
🇺🇸 English	Skip the client docs deploy step on pull requests from forks instead of failing the check
🇨🇳 Chinese	来自 fork 的 PR 上跳过客户端文档部署步骤，不再因缺少密钥而报失败

Docs

Language	Link
🇺🇸 English
🇨🇳 Chinese

Checklists

• All changes have been self-tested and work as expected
• Test cases are updated/provided or not needed
• Doc is updated/provided or not needed
• If documentation was changed, the corresponding files in all other languages have been updated to keep them in sync (or this change does not affect docs)
• Component demo is updated/provided or not needed
• Changelog is provided or not needed
• Request a code review if it is necessary

🤖 Generated with Claude Code

[Copilot]

🟢 Approval recommended

No unresolved review comments remain, and deployment behavior is preserved for trusted runs.

Pull request overview

Updates the client documentation workflow to avoid false failures for pull requests from forks.

Changes:

• Skips secret-dependent SSH deployment for fork PRs.
• Preserves documentation builds and deployment for pushes and same-repository PRs.

File summaries

File	Description
.github/workflows/deploy-client-docs.yml	Adds a fork-aware condition to the deployment step.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.