Skip to content

PLTF-3502: Add SonarQube analysis - #206

Draft
aivong-openhands wants to merge 5 commits into
mainfrom
av/sonarqube-scan
Draft

PLTF-3502: Add SonarQube analysis#206
aivong-openhands wants to merge 5 commits into
mainfrom
av/sonarqube-scan

Conversation

@aivong-openhands

@aivong-openhands aivong-openhands commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

Why

We're evaluating SonarQube as a code health scorecard across five repos, and this is the analysis config for this one. It scans main and manual dispatch only — deliberately not pull_request, which runs for forks and would put SONAR_TOKEN in reach of anyone who opens one. sonar-project.properties lists two Python roots (enterprise and the smaller openhands) because scanning only the first drops part of the app with no visible symptom, and both frontend trees get a dependency install since SonarJS resolves types from node_modules and quietly degrades without them. Neither install is a build; Python and TypeScript are analysed from source. The POC is time-boxed and the instance is disposable, so this is expected to be reverted rather than kept.

Coverage will report 0%. Supplying it means running the test suites inside the scan job, which the POC deliberately skips — that's a missing input rather than a finding, and worth saying before anyone reads the grade.

Validation

  • Paths check out against the repoenterprise/, openhands/, tests/, frontend/package-lock.json and openhands-ui/bun.lock all exist; openhands-ui is a separate Bun package with its own lockfile, not part of the npm tree.
  • Toolchain versions come from the repo.nvmrc (Node 22) and openhands-ui/.bun-version (1.2.17) rather than hardcoded, so this cannot drift from what the other workflows use.
  • All four actions pinned to full commit SHAs resolved from their latest releases, with the version in a trailing comment.
  • Project key is enterprise, matching the project the analysis token is scoped to. A mismatch fails on permissions or silently creates a second project.

This PR was drafted by an AI agent on behalf of the user.


Enterprise server image for this PR:

ghcr.io/openhands/enterprise-server:sha-c56ece4

Scans main and on manual dispatch only. No pull_request trigger: that runs for
forks, which would expose SONAR_TOKEN to anyone opening a PR.

Both frontend trees get a dependency install because SonarJS resolves types from
node_modules and degrades to a shallower analysis without them rather than
failing. frontend is npm, openhands-ui is a separate Bun package. Neither is a
build -- Python and TypeScript are both analysed from source.

Two Python roots are listed: enterprise and the smaller openhands. Scanning only
the first loses part of the app with no visible symptom.
@aivong-openhands aivong-openhands changed the title Add SonarQube analysis for the code health POC PLTF-3502: Add SonarQube analysis Aug 19, 2026
@linear

linear Bot commented Aug 19, 2026

Copy link
Copy Markdown

pull_request is temporary: Community Build has no branch analysis, so a PR scan
overwrites the main-branch report card until the next push to main. It is here to
prove the setup works and is marked for removal before merge.

The concurrency group matches the other workflows. The previous group keyed on
github.ref with cancel-in-progress, which on a main-only trigger would have
cancelled each in-flight scan as the next commit landed. Falling back to run_id
when head_ref is empty leaves main pushes alone.

ubuntu-24.04 rather than the ubuntu-22.04 the sibling workflows pin.
Community Build has no branch analysis, so a PR scan would overwrite the
main-branch report card with proposed code. The POC wants a baseline of what is
on main.
The scan aborted with "File enterprise/tests/__init__.py can't be indexed twice":
enterprise/tests is inside the enterprise source root, and SonarQube requires
sources and tests to be disjoint sets. The other test paths are siblings of their
source roots so they were never affected.

Restores the pull_request trigger. Community Build has a single branch per
project, so scanning the PR produces the repo's report card without merging --
which is the point for the POC.
@github-actions

Copy link
Copy Markdown

Coverage report

This PR does not seem to contain any modification to coverable code.

Coverage was reading 0% because no report reached the scanner. The reports exist,
but in other workflows on other runners: py-tests.yml uploads two binary
coverage files and fe-unit-tests.yml discards its lcov entirely.

Runs both Python suites and the frontend tests here instead, so coverage always
matches the analysed commit rather than whatever ran last. Frontend coverage is
regenerated rather than downloaded because fe-unit-tests.yml is path-filtered to
frontend/**, so a Python-only commit produces no artifact to fetch.

Test steps are continue-on-error: py-tests.yml gates correctness, this workflow
measures, and a failing test should still yield coverage to analyse.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant