Use pull_request_target event in PR workflow to support fork CI with secrets #59

New issue

Closed

opened 2026-04-13 15:20:14 +00:00 by GuillaumeHemmen · 0 comments

GuillaumeHemmen commented

2026-04-13 15:20:14 +00:00

Owner

Checklist

I have searched existing issues and pull requests to ensure this feature
has not been requested before
I have reviewed the documentation to confirm this feature doesn't already
exist
This feature aligns with the project's goals

Feature Description

Update the .forgejo/workflows/pr.yaml workflow to use the
pull_request_target event instead of pull_request, and adapt the checkout
steps to correctly check out the PR contributor's code.

Problem Statement

The current pull_request event does not have access to repository secrets when
triggered by a fork PR. This means optional steps like the Sonar analysis are
silently skipped for fork contributions, providing incomplete CI feedback and
reducing code quality visibility for external contributors.

Proposed Solution

Switch the workflow trigger from pull_request to pull_request_target:

The workflow runs in the context of the base branch (master), giving it access
to secrets for all PRs, including forks.
All actions/checkout@v4 steps must be updated to explicitly check out the PR
head commit using ref: ${{ github.event.pull_request.head.sha }}, so the
contributor's actual code is tested rather than the base branch.

Use Case

A contributor forks the repository and opens a PR. With pull_request, Sonar
analysis is skipped because SONAR_TOKEN is not accessible. With
pull_request_target and the adapted checkout, the full CI pipeline — including
Sonar — runs on the contributor's code.

Alternatives Considered

Keep pull_request and document that Sonar won't run on forks: Acceptable
but provides inconsistent CI experience and misses code quality reporting for
external contributions.
Use refs/pull/N/merge instead of the head SHA for checkout: This checks
out the merged result rather than the exact PR commit, introducing ambiguity.
Using the head SHA is more precise and aligns with Forgejo recommendations.

Examples

on:
  pull_request_target:
    branches:
      - master

jobs:
  prettier:
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}

Implementation Ideas

Edit .forgejo/workflows/pr.yaml: change event trigger and add ref: to all
checkout steps.
No other workflow files need to change.

Additional Context

This is a Forgejo CI environment. The pull_request_target event behaves
similarly to GitHub Actions' pull_request_target. See Forgejo Actions
documentation for details.

## Checklist - [x] I have searched existing issues and pull requests to ensure this feature has not been requested before - [x] I have reviewed the documentation to confirm this feature doesn't already exist - [x] This feature aligns with the project's goals ## Feature Description Update the `.forgejo/workflows/pr.yaml` workflow to use the `pull_request_target` event instead of `pull_request`, and adapt the checkout steps to correctly check out the PR contributor's code. ## Problem Statement The current `pull_request` event does not have access to repository secrets when triggered by a fork PR. This means optional steps like the Sonar analysis are silently skipped for fork contributions, providing incomplete CI feedback and reducing code quality visibility for external contributors. ## Proposed Solution Switch the workflow trigger from `pull_request` to `pull_request_target`: - The workflow runs in the context of the base branch (master), giving it access to secrets for all PRs, including forks. - All `actions/checkout@v4` steps must be updated to explicitly check out the PR head commit using `ref: ${{ github.event.pull_request.head.sha }}`, so the contributor's actual code is tested rather than the base branch. ## Use Case A contributor forks the repository and opens a PR. With `pull_request`, Sonar analysis is skipped because `SONAR_TOKEN` is not accessible. With `pull_request_target` and the adapted checkout, the full CI pipeline — including Sonar — runs on the contributor's code. ## Alternatives Considered - **Keep `pull_request` and document that Sonar won't run on forks**: Acceptable but provides inconsistent CI experience and misses code quality reporting for external contributions. - **Use `refs/pull/N/merge` instead of the head SHA for checkout**: This checks out the merged result rather than the exact PR commit, introducing ambiguity. Using the head SHA is more precise and aligns with Forgejo recommendations. ## Examples ```yaml on: pull_request_target: branches: - master jobs: prettier: steps: - uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha }} ``` ## Implementation Ideas - Edit `.forgejo/workflows/pr.yaml`: change event trigger and add `ref:` to all checkout steps. - No other workflow files need to change. ## Additional Context This is a Forgejo CI environment. The `pull_request_target` event behaves similarly to GitHub Actions' `pull_request_target`. See Forgejo Actions documentation for details.

GuillaumeHemmen added the

enhancement

label

2026-04-13 15:20:14 +00:00

GuillaumeHemmen self-assigned this

2026-04-13 15:20:14 +00:00

GuillaumeHemmen referenced this issue from a commit

2026-04-13 15:21:14 +00:00

#59 - Switch PR workflow to `pull_request_target` to support fork CI with secrets

GuillaumeHemmen added reference 59-Use-pull_request_target-event-in-PR-workflow-to-support-fork-CI-with-secrets

2026-04-13 15:21:19 +00:00

GuillaumeHemmen referenced this issue from a pull request that will close it,