Skip to content

docs: explain the Enable CI on your fork check in the contributor guide #7352

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
andygrove wants to merge 1 commit into
base: main
Choose a base branch
from
+36 −3
Open

docs: explain the Enable CI on your fork check in the contributor guide #7352

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 33 additions & 2 deletions docs/source/contributor-guide/ci.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -144,8 +144,7 @@ shows a result is rechecked only by a sweep that takes 25 open pull requests eve
is about two hours to go round 200 of them. So after you re-run a failed job in your fork, the pull
request can keep showing the old result for hours. Your fork's **Actions** tab is the source of truth:
read the details and re-run failed jobs there. If the check says **Enable CI on your fork** or **No fork CI
run for this commit**, no run was found for the pull request's head commit: Actions is disabled, the
branch does not include the fork workflows, or the run has not appeared yet.
run for this commit**, see [When the fork check finds no run](#when-the-fork-check-finds-no-run).

Some things to know:

Expand Down Expand Up @@ -177,6 +176,38 @@ If you cannot enable Actions on your fork, say so on the pull request. Nothing e
tier for you before the queue does, so a maintainer may ask you to reproduce a failure with
[`dev/local-ci.sh`](#reproducing-a-suite-failure-locally) first.

### When the fork check finds no run

When no run of your fork exists for the pull request's head commit, `CI (fork)` says one of two
things:

- **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

@sunchao sunchao Oct 30, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

go on.
- **No fork CI run for this commit.** The workflow exists but has no run for this commit. Either
the run has not appeared yet, or the commit was pushed before Actions was enabled.

Either way, the fix is the three steps above, followed by a new push:

```shell
# 1. Enable Actions in your fork's Actions tab, then:
git fetch upstream
git push origin upstream/main:main # 2. sync your fork's main (or use "Sync fork" on GitHub)
git merge upstream/main # 3. bring the fork workflows into your branch (or rebase)
git push # starts a Comet CI (fork run) in your fork
```

These commands assume the remote named `upstream` is `apache/datafusion-comet` and `origin` is your
fork. Enabling Actions does not start a run for commits already pushed, so a push is needed even
when your branch already includes the fork workflows. If `main` has nothing new to merge, an empty
commit (`git commit --allow-empty`) will do. The check picks up the new run within a few minutes.

A pull request opened before the PR tier moved to forks on 30 October 2026 had the PR tier run here
for the commits pushed up to then, and those results still show on it. The sweep still adds a
failed `CI (fork)` check to it, so set up your fork as above before your next push.

## Opting a pull request into a suite the PR tier skips

Each suite outside the PR tier has a label that runs it on a pull request:
Expand Down
4 changes: 3 additions & 1 deletion docs/source/contributor-guide/development.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -648,7 +648,9 @@ changes before retrying; do not switch to `--force` to bypass the check.

For a pull request from a fork, the pull request tier of CI runs on your fork's GitHub runners
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

@sunchao sunchao Oct 30, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

does not run on it; see [When the fork check finds no run](ci.md#when-the-fork-check-finds-no-run).

Before submitting a pull request, follow this checklist to ensure your changes are ready:

Expand Down