Make Sonar analysis step optional to support fork CI #56

New issue

Closed

opened 2026-04-13 10:17:36 +00:00 by GuillaumeHemmen · 0 comments

GuillaumeHemmen commented

2026-04-13 10:17:36 +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

Make the Sonar analysis step in the CI pipeline optional by reading sensitive
configuration from environment variables and skipping the step entirely when
those variables are absent.

Problem Statement

The CI pipeline currently fails for forks because:

sonar-project.properties hardcodes several values tied to the upstream
repository: sonar.host.url (a private SonarQube instance unreachable from
forks), sonar.projectKey, and sonar.projectName.
The SONAR_TOKEN secret is only available in the upstream repository.

As a result, any contributor who forks the project and opens a PR from their
fork will have the sonar CI job fail, even though their code changes are
perfectly valid.

Proposed Solution

Move the following properties out of sonar-project.properties and into CI
environment variables (passed via repository secrets):

Property	Environment variable
`sonar.host.url`	`SONAR_HOST_URL`
`sonar.projectKey`	`SONAR_PROJECT_KEY`
`sonar.projectName`	`SONAR_PROJECT_NAME`

Add a skip condition (if: ${{ secrets.SONAR_TOKEN != '' }}) to the sonar job
in all four workflow files. The step should be skipped (not failed) when
the variable is absent, so fork CI passes cleanly.

Expected behavior

Context	`SONAR_TOKEN` present	Sonar job result
Upstream repo PR	yes	runs normally
Fork PR	no	skipped

Use Case

A contributor forks the repository, makes a change, and opens a PR from their
fork. Today the sonar job blocks their CI with an authentication/connection
error. After this change, the job is skipped and the PR shows a green pipeline.

Alternatives Considered

Migrate to SonarCloud (free for open-source): Would still require forkers
to configure their own org/project, so the skip logic would still be needed.
Document Sonar as maintainer-only: Simpler but leaves a broken CI
experience for contributors with no explanation.

Implementation Ideas

All four workflows need the same changes to their sonar job: add the if
condition and inject the new env vars. Each workflow has a slightly different
sonar-scanner invocation:

.forgejo/workflows/pr.yaml

sonar:
  if: ${{ secrets.SONAR_TOKEN != '' }}
  env:
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
    SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
    SONAR_PROJECT_KEY: ${{ secrets.SONAR_PROJECT_KEY }}
    SONAR_PROJECT_NAME: ${{ secrets.SONAR_PROJECT_NAME }}
  steps:
    - name: run sonar (PR analysis)
      run: |
        sonar-scanner \
          -Dsonar.host.url=$SONAR_HOST_URL \
          -Dsonar.projectKey=$SONAR_PROJECT_KEY \
          -Dsonar.projectName=$SONAR_PROJECT_NAME \
          -Dsonar.pullrequest.key=${{ github.event.pull_request.number }} \
          -Dsonar.pullrequest.branch=${{ github.head_ref }} \
          -Dsonar.pullrequest.base=${{ github.base_ref }};

.forgejo/workflows/master.yaml and .forgejo/workflows/dev.yaml

sonar:
  if: ${{ secrets.SONAR_TOKEN != '' }}
  env:
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
    SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
    SONAR_PROJECT_KEY: ${{ secrets.SONAR_PROJECT_KEY }}
    SONAR_PROJECT_NAME: ${{ secrets.SONAR_PROJECT_NAME }}
  steps:
    - name: run sonar
      run: |
        sonar-scanner \
          -Dsonar.host.url=$SONAR_HOST_URL \
          -Dsonar.projectKey=$SONAR_PROJECT_KEY \
          -Dsonar.projectName=$SONAR_PROJECT_NAME \
          -Dsonar.branch.name=$GITHUB_REF_NAME;

.forgejo/workflows/tag.yaml

Same env vars as above; the sonar-scanner invocation is also branch-based
(-Dsonar.branch.name=$GITHUB_REF_NAME). Note: in tag.yaml the publish job
depends on sonar (needs: sonar) — this dependency must be kept or adjusted
so that publish is not blocked when sonar is skipped.

sonar-project.properties — remove hardcoded values:

-sonar.host.url=https://sonarqube.van-hemmen.com
-sonar.projectKey=react-native-logging-tools
-sonar.projectName=react-native-logging-tools

Additional Context

Affected files:

.forgejo/workflows/pr.yaml
.forgejo/workflows/master.yaml
.forgejo/workflows/dev.yaml
.forgejo/workflows/tag.yaml
sonar-project.properties
CONTRIBUTING.md (document the required secrets and how to enable Sonar on a fork)

Documentation to add in CONTRIBUTING.md:

A new section explaining how to enable Sonar analysis on a forked repository:

Set up a SonarQube instance (or use SonarCloud).
Create a project and generate a token.
Add the following secrets to the forked repository's CI settings:
- SONAR_TOKEN — authentication token for the SonarQube instance
- SONAR_HOST_URL — URL of the SonarQube instance (e.g. https://sonarcloud.io)
- SONAR_PROJECT_KEY — project key as defined in SonarQube
- SONAR_PROJECT_NAME — project name as defined in SonarQube
The Sonar job will automatically activate once SONAR_TOKEN is present.

## 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 Make the Sonar analysis step in the CI pipeline optional by reading sensitive configuration from environment variables and skipping the step entirely when those variables are absent. ## Problem Statement The CI pipeline currently fails for forks because: 1. `sonar-project.properties` hardcodes several values tied to the upstream repository: `sonar.host.url` (a private SonarQube instance unreachable from forks), `sonar.projectKey`, and `sonar.projectName`. 2. The `SONAR_TOKEN` secret is only available in the upstream repository. As a result, any contributor who forks the project and opens a PR from their fork will have the `sonar` CI job fail, even though their code changes are perfectly valid. ## Proposed Solution Move the following properties out of `sonar-project.properties` and into CI environment variables (passed via repository secrets): | Property | Environment variable | |---|---| | `sonar.host.url` | `SONAR_HOST_URL` | | `sonar.projectKey` | `SONAR_PROJECT_KEY` | | `sonar.projectName` | `SONAR_PROJECT_NAME` | Add a skip condition (`if: ${{ secrets.SONAR_TOKEN != '' }}`) to the `sonar` job in **all four workflow files**. The step should be **skipped** (not failed) when the variable is absent, so fork CI passes cleanly. ### Expected behavior | Context | `SONAR_TOKEN` present | Sonar job result | |------------------|-----------------------|------------------| | Upstream repo PR | yes | runs normally | | Fork PR | no | skipped | ## Use Case A contributor forks the repository, makes a change, and opens a PR from their fork. Today the `sonar` job blocks their CI with an authentication/connection error. After this change, the job is skipped and the PR shows a green pipeline. ## Alternatives Considered - **Migrate to SonarCloud (free for open-source):** Would still require forkers to configure their own org/project, so the skip logic would still be needed. - **Document Sonar as maintainer-only:** Simpler but leaves a broken CI experience for contributors with no explanation. ## Implementation Ideas All four workflows need the same changes to their `sonar` job: add the `if` condition and inject the new env vars. Each workflow has a slightly different `sonar-scanner` invocation: **`.forgejo/workflows/pr.yaml`** ```yaml sonar: if: ${{ secrets.SONAR_TOKEN != '' }} env: SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }} SONAR_PROJECT_KEY: ${{ secrets.SONAR_PROJECT_KEY }} SONAR_PROJECT_NAME: ${{ secrets.SONAR_PROJECT_NAME }} steps: - name: run sonar (PR analysis) run: | sonar-scanner \ -Dsonar.host.url=$SONAR_HOST_URL \ -Dsonar.projectKey=$SONAR_PROJECT_KEY \ -Dsonar.projectName=$SONAR_PROJECT_NAME \ -Dsonar.pullrequest.key=${{ github.event.pull_request.number }} \ -Dsonar.pullrequest.branch=${{ github.head_ref }} \ -Dsonar.pullrequest.base=${{ github.base_ref }}; ``` **`.forgejo/workflows/master.yaml` and `.forgejo/workflows/dev.yaml`** ```yaml sonar: if: ${{ secrets.SONAR_TOKEN != '' }} env: SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }} SONAR_PROJECT_KEY: ${{ secrets.SONAR_PROJECT_KEY }} SONAR_PROJECT_NAME: ${{ secrets.SONAR_PROJECT_NAME }} steps: - name: run sonar run: | sonar-scanner \ -Dsonar.host.url=$SONAR_HOST_URL \ -Dsonar.projectKey=$SONAR_PROJECT_KEY \ -Dsonar.projectName=$SONAR_PROJECT_NAME \ -Dsonar.branch.name=$GITHUB_REF_NAME; ``` **`.forgejo/workflows/tag.yaml`** Same env vars as above; the `sonar-scanner` invocation is also branch-based (`-Dsonar.branch.name=$GITHUB_REF_NAME`). Note: in `tag.yaml` the `publish` job depends on `sonar` (`needs: sonar`) — this dependency must be kept or adjusted so that publish is not blocked when sonar is skipped. **`sonar-project.properties` — remove hardcoded values:** ```diff -sonar.host.url=https://sonarqube.van-hemmen.com -sonar.projectKey=react-native-logging-tools -sonar.projectName=react-native-logging-tools ``` ## Additional Context Affected files: - `.forgejo/workflows/pr.yaml` - `.forgejo/workflows/master.yaml` - `.forgejo/workflows/dev.yaml` - `.forgejo/workflows/tag.yaml` - `sonar-project.properties` - `CONTRIBUTING.md` (document the required secrets and how to enable Sonar on a fork) **Documentation to add in `CONTRIBUTING.md`:** A new section explaining how to enable Sonar analysis on a forked repository: 1. Set up a SonarQube instance (or use SonarCloud). 2. Create a project and generate a token. 3. Add the following secrets to the forked repository's CI settings: - `SONAR_TOKEN` — authentication token for the SonarQube instance - `SONAR_HOST_URL` — URL of the SonarQube instance (e.g. `https://sonarcloud.io`) - `SONAR_PROJECT_KEY` — project key as defined in SonarQube - `SONAR_PROJECT_NAME` — project name as defined in SonarQube 4. The Sonar job will automatically activate once `SONAR_TOKEN` is present.

GuillaumeHemmen added the

enhancement

label

2026-04-13 10:17:36 +00:00

GuillaumeHemmen self-assigned this

2026-04-13 10:17:36 +00:00

GuillaumeHemmen added reference 56-Make-Sonar-analysis-step-optional-to-support-fork-CI

2026-04-13 10:18:21 +00:00

GuillaumeHemmen referenced this issue from a commit

2026-04-13 11:19:34 +00:00

#56 - make Sonar analysis optional to support fork CI, update documentation

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