Gate Sonar/Codecov on secret availability + run them safely on fork PRs

[AndreasIgel]

Upstream counterpart of fork PR AndreasIgel#11. Head branch: AndreasIgel/simple-builders-fork:feature/164-fork-pr-secret-gating → base java-helpers/simple-builders:main.

Summary

Makes external-fork (and Dependabot) PRs stop showing a red build check for reasons unrelated to the change, and adds a safe way to actually run the secret-backed quality checks (Codecov + SonarCloud) on fork PRs.

Fixes #164
Fixes #198

Part 1 — Don't hard-fail fork/Dependabot PRs (issue #164)

The SonarCloud and Codecov steps were gated only on github.actor != 'dependabot[bot]'. Fork PRs don't receive repository secrets, so the steps ran without tokens and hard-failed (fail_ci_if_error: true). Fix: expose the tokens as job-level env and gate each step on the env value being non-empty:

jobs:
  build:
    env:
      SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
      CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
    steps:
      - name: SonarCloud Analysis
        if: env.SONAR_TOKEN != ''          # was: github.actor != 'dependabot[bot]'
      - name: Upload ... to Codecov
        if: always() && env.CODECOV_TOKEN != ''

On fork/Dependabot PRs secrets resolve to '', so these steps are skipped cleanly; for same-repo PRs and pushes they run as before (still fail_ci_if_error: true).

Part 2 — Run the quality checks on fork PRs safely (issue #198)

Because fork pull_request runs have no secrets, the checks are performed from the base-repository context after the unprivileged CI run. The unprivileged workflow always owns the build, generated-source check, and tests; the privileged workflows only publish their results.

Codecov — .github/workflows/fork-coverage.yml (automatic, no fork code executed).
The main CI build (which runs the fork code without secrets) publishes the JaCoCo XML + test reports plus the PR identity as an artifact. A follow-up workflow_run workflow downloads only that artifact and has exactly two publishing steps: test execution results and test coverage. Test execution results are uploaded even when the build/test job fails when reports exist, so Codecov receives useful diagnostics. Coverage is published only after a successful CI run, and it cannot make a failed CI check pass. PR #184 sets codecov.require_ci_to_pass: true, so a successful Codecov status also requires the CI workflow to pass.

SonarCloud — .github/workflows/fork-sonar.yml (manual maintainer approval).
A workflow_run starts only after the fork CI succeeds. It restores the compiled classes and JaCoCo reports produced by that unprivileged run, then has one publishing step for SonarCloud. It does not rebuild or retest fork code while SONAR_TOKEN is available. The workflow checks out the exact successful fork commit so Sonar can inspect its source, and remains gated by the fork-ci GitHub Environment with Required reviewers.

A maintainer reviews the diff and clicks Approve; the analysis then runs on their behalf with SONAR_TOKEN. SonarCloud decorates the PR server-side via the token configured in its project settings.

Maintainer setup required

Create a repository Environment named fork-ci (Settings → Environments) with Required reviewers = the maintainer(s). Without it the Sonar job would not have the mandatory manual safety gate.

Why the fork checks can't be seen running on this PR yet

fork-coverage.yml and fork-sonar.yml use workflow_run, and GitHub runs workflow_run (and pull_request_target) workflows only from the version on the default branch. They live only on this feature branch, so they do not trigger — and the environment approval prompt does not appear — until this PR is merged into main. After merge, the next fork-PR CI run produces the artifact, fork-sonar.yml starts and pauses on the fork-ci environment for a maintainer to Approve. (Also fixed: workflow_run.pull_requests is empty for fork runs, so the PR number/branch/base are now read from the CI artifact, and the source is checked out from the base repo's refs/pull/<n>/head.)

Manual runs

Both fork workflows also expose a workflow_dispatch trigger with a run_id input, so a maintainer can start them on demand from the Actions tab for a specific "Java CI with Maven" fork-PR run (e.g. to re-publish coverage or run Sonar). The fork-ci environment approval still applies to the Sonar dispatch.

Validation

• actionlint passes on maven.yml, fork-coverage.yml, fork-sonar.yml.
• Workflow-only change; Maven build unaffected.
• End-to-end Codecov/Sonar behavior can only be confirmed once merged (needs the base-repo secrets + the fork-ci environment), as noted above.

Maintainer TODOs (required before the fork checks work)

• Create the fork-ci Environment (Settings → Environments → New environment → fork-ci) and add yourself (a maintainer) under Required reviewers. fork-sonar.yml references this environment as its approval gate; without it the Sonar job would run untrusted fork code with secrets automatically, which is unsafe.
• Confirm the SonarCloud decoration mechanism in the SonarCloud project settings: verify PR decoration uses a token configured in the project settings (not the GitHub App). This is the assumption behind dropping pull-requests: write (Drop unnecessary pull-requests: write scope from the Maven CI job #187) and behind the fork-Sonar design.
• Ensure the SONAR_TOKEN and CODECOV_TOKEN repository secrets exist (they are already used by the main CI); no new secrets are introduced by this PR.

[AndreasIgel]

Should be given to manual reviewer instead, who would start the review on behalf and by that use the corresponding token.

[AndreasIgel]

Implemented as requested: added .github/workflows/fork-sonar.yml, gated by the fork-ci GitHub Environment (Required reviewers). A maintainer approves the run, and the analysis then executes on their behalf using SONAR_TOKEN. This PR now also Fixes #198 and documents the setup (see updated description + docs/CONTRIBUTING.md). One manual step for you: create the fork-ci environment with yourself as a required reviewer.