Skip to content

ci: finish PR verification hardening #472

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
BigSimmo merged 2 commits into from
Jul 10, 2026
+62 −28
Merged

ci: finish PR verification hardening #472

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d6c5802
ci: finish PR verification hardening
BigSimmo Jul 10, 2026
3b70840
Merge remote-tracking branch 'origin/main' into codex/pr-check-followup
BigSimmo Jul 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 6 additions & 4 deletions .github/workflows/ci.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,7 @@ permissions:
env:
NEXT_PUBLIC_SUPABASE_URL: https://sjrfecxgysukkwxsowpy.supabase.co
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY: placeholder-ci-anon-key
SUPABASE_CLI_VERSION: 2.108.0

jobs:
changes:
Expand Down Expand Up @@ -305,15 +306,16 @@ jobs:
- name: Setup Supabase CLI
uses: supabase/setup-cli@v3
with:
version: latest
version: ${{ env.SUPABASE_CLI_VERSION }}

- name: Restore Supabase Docker image cache
id: supabase-docker-cache
uses: actions/cache@v6
with:
path: /tmp/supabase-docker-cache
key: supabase-docker-${{ runner.os }}-${{ hashFiles('supabase/config.toml') }}
key: supabase-docker-${{ runner.os }}-cli-${{ env.SUPABASE_CLI_VERSION }}-${{ hashFiles('supabase/config.toml') }}
restore-keys: |
supabase-docker-${{ runner.os }}-
supabase-docker-${{ runner.os }}-cli-${{ env.SUPABASE_CLI_VERSION }}-

- name: Load cached Supabase Docker images
run: |
Expand All @@ -328,7 +330,7 @@ jobs:
run: supabase db reset

- name: Save Supabase Docker images
if: always()
if: success() && steps.supabase-docker-cache.outputs.cache-hit != 'true'
continue-on-error: true
run: |
mkdir -p /tmp/supabase-docker-cache
Expand Down
19 changes: 10 additions & 9 deletions .github/workflows/sast.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,15 +15,16 @@ permissions:
contents: read

jobs:
# Static application security testing. Semgrep is used instead of CodeQL
# Advisory static application security testing. Semgrep is used instead of CodeQL
# because this repository is private without GitHub Advanced Security, so the
# code-scanning SARIF upload CodeQL relies on is unavailable; a build-failing
# scan mirrors the existing `npm audit` gate in ci.yml. The document parsers
# code-scanning SARIF upload CodeQL relies on is unavailable. The document parsers
# (pdf-parse, pdfjs-dist, mammoth, exceljs, jszip) and the answer/ingestion
# paths process untrusted uploaded documents, so ERROR-severity findings block
# the merge. Runs OSS-engine only — no Semgrep account or token required.
# paths process untrusted uploaded documents, so ERROR-severity findings remain
# visible without making mutable registry rules a required merge dependency.
# Runs OSS-engine only — no Semgrep account or token required.
semgrep:
name: Semgrep
continue-on-error: true
Comment on lines 25 to +27

@coderabbitai coderabbitai Bot Jul 10, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Show the relevant workflow file with line numbers.
if [ -f .github/workflows/sast.yml ]; then
  wc -l .github/workflows/sast.yml
  sed -n '1,220p' .github/workflows/sast.yml | cat -n
else
  echo "File not found: .github/workflows/sast.yml"
  exit 1
fi

Repository: BigSimmo/Database

Length of output: 2298

🌐 Web query:

GitHub Actions job-level continue-on-error failed step checkout container initialization workflow passes without running later steps

💡 Result:

In GitHub Actions, the continue-on-error: true attribute is designed to prevent a job from failing when a specific step fails, allowing subsequent steps in that job to execute [1][2]. If your workflow appears to stop after a step with continue-on-error: true fails, it is likely due to one of the following reasons: 1. Step Outcome vs. Conclusion: When continue-on-error is set to true, the step's outcome will reflect the actual failure (e.g., 'failure'), but the step's conclusion will be 'success' because the error was suppressed [3][4]. If you have subsequent steps that use conditional logic (e.g., if: failure()), they will not run because GitHub Actions evaluates them based on the step's conclusion [3][4]. To detect the failure in later steps, you should check the outcome property instead: if: steps.<step_id>.outcome == 'failure' [2][4]. 2. Container Initialization Issues: If the failure occurs during "container initialization" (e.g., pulling an image, mounting volumes, or setting up the container environment), it may represent a platform-level or infrastructure error that occurs outside the scope of individual step execution. In some cases, if the runner itself cannot initialize the environment for subsequent steps, the job may terminate despite the continue-on-error flag [5]. 3. Nested Action Failure: continue-on-error generally works at the immediate step level [5]. If the failure occurs deep within a nested composite action or a sub-action that itself calls other actions, the continue-on-error flag on the outer step may not successfully mask failures occurring in certain internal processes (such as post-actions or deep-level node scripts) [5]. To troubleshoot, inspect the logs for any error messages occurring after the failed step, as these often indicate if the runner aborted the job due to infrastructure constraints rather than a simple step failure [5].

Citations:

🌐 Web query:

GitHub Actions jobs.<job_id>.continue-on-error job-level semantics step failures checkout failure workflow conclusion

💡 Result:

In GitHub Actions, the continue-on-error property behaves differently depending on whether it is applied to a specific step or an entire job [1]. For steps, jobs.<job_id>.steps[*].continue-on-error allows a job to continue executing subsequent steps even if the specific step fails [2]. When a step with continue-on-error: true fails, the step's outcome is failure, but its final conclusion is recorded as success [3][4]. This allows the job to proceed, effectively masking the failure at the step level [2]. For jobs, jobs.<job_id>.continue-on-error prevents the entire workflow run from failing if the specific job fails [1]. When set to true, the workflow run is permitted to pass even if that job fails [1]. It is important to note that using continue-on-error does not make the job "succeed" in a technical sense; it primarily affects the workflow's overall completion status [5][4]. Because the job itself may still report a failure internally, conditional expressions like if: failure() or needs.<job_id>.result may behave unexpectedly if you rely on them to detect the "true" outcome of a job [6][5]. The job's internal failure status remains, which can impact dependent jobs if they are configured to run based on the outcome of the job that used continue-on-error [5][7]. If a job fails or is skipped, all downstream jobs that depend on it are typically skipped unless they use conditional expressions to continue [7].

Citations:

Move continue-on-error to the Semgrep scan step. At the job level, checkout or container setup failures also become advisory, so the workflow can pass without ever running Semgrep.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/sast.yml around lines 25 - 27, Move continue-on-error:
true from the Semgrep job definition to the specific Semgrep scan step, keeping
checkout, setup, and container initialization failures blocking while allowing
only scan findings to be advisory.

runs-on: ubuntu-24.04
timeout-minutes: 15
container:
Expand All @@ -36,9 +37,9 @@ jobs:

- name: Semgrep scan
# --error fails the job on any ERROR-severity finding; --oss-only keeps
# it token-free; --metrics off sends no telemetry. Rulesets are pinned by
# name (no network `auto` inference). Secrets are covered by Gitleaks in
# secret-scan.yml, so no p/secrets here. Scope is source only.
# it token-free; --metrics off sends no telemetry. Named registry rules
# remain advisory because they can change independently of this repository.
# Secrets are covered by Gitleaks in secret-scan.yml, so no p/secrets here.
run: >
semgrep scan
--error
Expand All @@ -49,4 +50,4 @@ jobs:
--config p/javascript
--config p/react
--config p/nodejs
src worker scripts
src worker scripts supabase/functions
Loading