Repository navigation
Conversation
github-actions
Bot
added
the
documentation
sunchao
left a comment
sunchao
left a comment
There was a problem hiding this comment.
The setup commands point contributors to the right workflow. I found two places where the text overstates what the fork check can establish. The inline comments include examples from this rollout.
| - **Enable CI on your fork.** Your fork has no enabled `Comet CI (fork run)` workflow. Usually | ||
| GitHub Actions was never enabled on the fork, or no branch that includes the fork workflows has | ||
| been pushed to it. GitHub shows this check as failed because it asks you to act. It does not block | ||
| merging, but the PR tier has not run on this commit anywhere, so a reviewer has no CI result to |
There was a problem hiding this comment.
A missing fork run establishes only that the mirror found no run on the fork for this SHA. On #7316, commit cd5dda1c has both “Enable CI on your fork” and a successful upstream PR-tier Rust job. Could we say that earlier upstream results may still exist? The rollout paragraph below also predicts a failed check for older PRs, but #7326 received the neutral “No fork CI run for this commit” outcome. #7316 fork check · #7316 upstream test · #7326 neutral check
| rather than the project's. Enable GitHub Actions on your fork and keep its `main` in sync before you | ||
| push; see [Pull requests from forks](ci.md#pull-requests-from-forks). | ||
| push; see [Pull requests from forks](ci.md#pull-requests-from-forks). Until you do, the pull | ||
| request shows a failed `CI (fork)` check that says **Enable CI on your fork**, and the PR tier |
There was a problem hiding this comment.
Could we qualify this as a fork PR targeting main? The mirror filters on pr.base.ref === 'main'. Fork PRs targeting a release branch run their PR tier upstream, so contributors to those branches won’t see this check. #7351 is a current example. Mirror filter · #7351 upstream run
Which issue does this PR close?
No issue filed. Follow-up to #7311.
Rationale for this change
Since #7311, the PR tier for a fork pull request into
mainruns on the contributor's fork, and theCI (fork)check mirrors that run onto the pull request. When the fork has Actions disabled, the check reports Enable CI on your fork, which GitHub shows as a failure. Most forks have Actions disabled, because GitHub disables workflows on a new fork, so this check is now showing up on fork pull requests such as #7343. The guide covered the setup steps, but only one sentence covered this failure, and it did not say what the red check means for merging, what to run, or why a pull request opened before the change gets it too.What changes are included in this PR?
ci.md: a new "When the fork check finds no run" subsection under "Pull requests from forks". It explains the two messages (Enable CI on your fork and No fork CI run for this commit), says the check does not block merging but means the PR tier has not run, and gives the commands to fix it. It also notes that enabling Actions needs a new push, and covers pull requests opened before the change. The old one-sentence explanation now links to the subsection. The check's own details link still lands on "Pull requests from forks", directly above the new subsection.development.md: the fork paragraph under "Submitting a Pull Request" now names the failing check and links to the subsection.How are these changes tested?
Documentation only. Checked with prettier. The described behavior matches
fork_ci_status.ymlonmain.