From fd5f9be57d0f6ff0f9615f7c91176a23f1fe8b8f Mon Sep 17 00:00:00 2001 From: Daniel Han Date: Sat, 16 May 2026 10:00:40 +0000 Subject: [PATCH] ci: run OXC tarball scan even when frontend scan exits nonzero Reviewer found a real bug in 0ddfc10: the new two-scan step ran under `set -o pipefail` (default `set -e` from the step shell), so a HIGH or CRITICAL on the frontend lockfile would abort the step before the OXC scan ran. Both reports are most useful exactly when one has already failed. Capture each rc via PIPESTATUS, run both scans unconditionally, write both into the step summary, and only then propagate the worst rc. --- .github/workflows/security-audit.yml | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/.github/workflows/security-audit.yml b/.github/workflows/security-audit.yml index 3f9a3610bb..10293a1286 100644 --- a/.github/workflows/security-audit.yml +++ b/.github/workflows/security-audit.yml @@ -934,14 +934,23 @@ jobs: # continue-on-error once the baseline is clean for a week. # # Two separate npm projects share this scan surface; scan each. + # Capture exit codes via PIPESTATUS so a HIGH/CRITICAL on the + # frontend lockfile does not skip the OXC scan (both reports + # are most useful exactly when one already failed). run: | + set +e set -o pipefail + LOG=logs-scan-npm.txt python3 scripts/scan_npm_packages.py 2>&1 | tee "$LOG" + frontend_rc=${PIPESTATUS[0]} + LOG2=logs-scan-npm-oxc.txt python3 scripts/scan_npm_packages.py \ --lockfile studio/backend/core/data_recipe/oxc-validator/package-lock.json \ 2>&1 | tee "$LOG2" + oxc_rc=${PIPESTATUS[0]} + { echo "## scan_npm_packages (Studio frontend)" echo @@ -958,6 +967,11 @@ jobs: echo '```' } >> "$GITHUB_STEP_SUMMARY" + if [ "$frontend_rc" -ne 0 ]; then + exit "$frontend_rc" + fi + exit "$oxc_rc" + - uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1 if: always() with: