My-Weekly-ToDo-List/.github/workflows/sonarqube.yml
mARTin-B78 6c0bf23104
Some checks are pending
Playwright Tests / test (push) Waiting to run
Test and SonarQube / quality (push) Waiting to run
fix: Node-Heap fuer SonarQube-Analyse-Bridge im GitHub-Actions-Runner erhoehen
Nachdem SONAR_TOKEN als GitHub-Secret gesetzt ist (frisches Token vom Besitzer, siehe
CHANGELOG v1.125.2), authentifiziert der Sonar-Schritt jetzt erfolgreich -- scheiterte im
ersten echten Testlauf aber an einem neuen, unabhaengigen Problem: der Standard-Node-Heap
der JS/TS-Analyse-Bridge (~2,2 GB) reicht auf dem GitHub-Hosted-Runner fuer dieses Repo
nicht ("Node.js process running out of memory"). Dieselbe Fehlerklasse wie der
next-build-OOM-Absturz auf dem Produktionscontainer (v1.119.3/v1.119.4).

-Dsonar.javascript.node.maxspace=4096 ergaenzt.

v1.125.3

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-12 20:57:58 +02:00

67 lines
2.4 KiB
YAML

name: Test and SonarQube
on:
push:
branches: [main]
workflow_dispatch:
permissions:
contents: read
jobs:
quality:
runs-on: ubuntu-latest
steps:
- name: Check out repository
uses: actions/checkout@v4
with:
# Full history so SonarQube can read blame data for new-code detection.
fetch-depth: 0
- name: Set up Node
uses: actions/setup-node@v4
with:
node-version: lts/*
cache: npm
- name: Install dependencies
run: npm ci
- name: Type check
run: npm run type-check
- name: Lint
run: npm run lint
- name: Unit tests
run: npm run test:unit
# continue-on-error bleibt auch mit gesetztem SONAR_TOKEN sinnvoll: der selbst
# gehostete SonarQube-Server kann mal nicht erreichbar sein, ohne dass das den Rest
# des Workflows mitreissen soll. Ein "if:" auf "secrets.SONAR_TOKEN != ''" waere die
# naheliegende Alternative fuer den Fall eines fehlenden Secrets, macht den Workflow
# bei diesem Runner aber ungueltig (0s-Fehlschlag ohne jeden Job-Log) -- deshalb
# bewusst nur continue-on-error statt eines bedingten Schritts.
#
# sonar.javascript.node.maxspace=4096: der Standard-Node-Heap der Analyse-Bridge
# (rund 2,2 GB) reicht auf dem GitHub-Hosted-Runner fuer dieses Repo nicht --
# WeeklyView.tsx allein ist riesig. Ohne das stirbt die Bridge mit "Node.js process
# running out of memory", der Scan schlaegt fehl (aufgefangen von continue-on-error,
# aber dann laeuft gar keine Analyse). Live beobachtet beim ersten echten Testlauf
# mit gueltigem Token am 12.09.2026 -- exakt dieselbe Ursachenklasse wie der
# OOM-Absturz von "next build" auf dem Produktionscontainer (siehe CHANGELOG v1.119.4).
- name: SonarQube scan
continue-on-error: true
uses: SonarSource/sonarqube-scan-action@v8.1.0
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SONAR_HOST_URL: ${{ vars.SONAR_HOST_URL }}
with:
args: >-
-Dsonar.projectKey=mARTin-B78_My-Weekly-ToDo-List_e038f066-0063-4a1e-9c33-03fdd5ab3c3a
-Dsonar.sources=src,scripts
-Dsonar.exclusions=**/node_modules/**,**/.next/**,**/*.spec.ts
-Dsonar.javascript.node.maxspace=4096
-Dsonar.qualitygate.wait=true
-Dsonar.qualitygate.timeout=300