SQL: PostgreSQL extensions (PGXS Makefile, *.control, sql/*.sql, pg_regress/TAP tests) are not recognised; scan-build --status-bugs is not a static analyzer run

Aperta
#276 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c, github-actions, postgresql, python, sql

Direzione di ricerca

Start with ecosystems/sql.py around sql_project (lines 291-297), which only recognises _TOOL_FILES, Flyway paths and pgTAP, then with tools/wrappers.py:13, which treats scan-build as a transparent launcher. Also check ecosystems/c_cpp/ for missing installcheck/prove handling. Done means a PGXS repo fixture (foo.control, sql/, test/sql) is detected as SQL with its pg_regress tests credited, and scan-build --status-bugs make is no longer read as plain make. This spans several subsystems, so ask a maintainer before starting.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

pgvector and pgaudit are the SQL ecosystem's archetype outside dbt (EXTENSION, MODULE_big, DATA = sql/*.sql, REGRESS =, TAP_TESTS = 1, test/sql + test/expected), yet .sql ×57 is unrecognised and the projects are plain C. Their pg_regress and TAP tests run in every CI job (make installcheck, make prove_installcheck) → "no tests found (CTest or Meson)"; pgvector's mac job runs the Clang Static Analyzer with scan-build --status-bugs make (fails on any finding) → "no static analyzer runs" (scan-build is listed as a transparent wrapper in tools/wrappers.py:13). The matrix that matters is the server version (ankane/setup-postgres postgres-version, 15–20) and the valgrind job (check-ub: yes) is the ecosystem's memory/UB check. dbt-utils' ci.yml runs only on workflow_dispatch and create-table-of-contents.yml has on: [], yet ci-present lists both as CI.

Evidence from the corpus audit

pgvector/pgvector, pgaudit/pgaudit / detection
  • kind: DETECTION
  • actual: map: languages ["C"], ecosystems C/C++, Data, Docker; unrecognised_suffixes: .sql (57 / 2 files),
    .control (1), .out (14 / 1), .pl (48 / 1)
  • expected: SQL detected: both are PostgreSQL extensions, the SQL ecosystem's archetype outside dbt; the control file,
    the PGXS Makefile (EXTENSION, MODULE_big, DATA = sql/*.sql) and test/sql + test/expected are unambiguous
  • evidence: pgvector vector.control:1: comment = 'vector data type and ivfflat and hnsw access methods';
    Makefile:1: EXTENSION = vector; Makefile:5: DATA = $(wildcard sql/*--*--*.sql); pgaudit Makefile:1:
    MODULE_big = pgaudit, Makefile:7: EXTENSION = pgaudit; validator ecosystems/sql.py:291-297 (sql_project)
    recognises only _TOOL_FILES, Flyway/migrations/ paths and pgTAP SELECT plan(; docs/ecosystems/sql.md:3-7
    documents the same list
  • repro: a repo with foo.control, Makefile containing EXTENSION = foo / PGXS := $(shell $(PG_CONFIG) --pgxs),
    sql/foo--1.0.sql, test/sql/a.sql, test/expected/a.out
  • confidence: high
pgvector/pgvector, pgaudit/pgaudit / tests-run
  • kind: FALSE_NEGATIVE
  • actual: FAIL: "no tests found (tests registered with CTest (...) or tests registered with Meson's test() in meson.build)"
  • expected: PASS: pg_regress tests (REGRESS =) and TAP tests (TAP_TESTS = 1, test/t/*.pl) exist and every CI
    job runs them with make installcheck / make prove_installcheck
  • evidence: pgvector Makefile:10-11: TESTS = $(wildcard test/sql/*.sql) / REGRESS = $(patsubst test/sql/%.sql,%,$(TESTS)); Makefile:60: prove_installcheck:; .github/workflows/build.yml:35: - run: make installcheck, :41: - run: make prove_installcheck, :125-126: sudo -u postgres make installcheck /
    sudo -u postgres make prove_installcheck; pgaudit Makefile:12: REGRESS = pgaudit, :15: TAP_TESTS = 1,
    test/test.sh:14: make -C /pgaudit installcheck USE_PGXS=1; validator: no installcheck/pg_regress/prove
    anywhere under ecosystems/c_cpp/ (grep returns nothing)
  • repro: Makefile with REGRESS = a + include $(PGXS), test/sql/a.sql, workflow step run: make installcheck
  • confidence: high
pgvector/pgvector / static-analysis
  • kind: FALSE_NEGATIVE (also UNREAD: no unknown raised)
  • actual: FAIL: "C/C++: no static analyzer runs"
  • expected: PASS (or ERROR in the strict run): the mac job runs the Clang Static Analyzer over the whole build with
    --status-bugs, which fails the job on any finding
  • evidence: .github/workflows/build.yml:77: - run: make clean && $(brew --prefix llvm@$LLVM_VERSION)/bin/scan-build --status-bugs make; validator tools/wrappers.py:13: *((name,) for name in ("emcmake", "emmake", "emconfigure", "scan-build", "ccache", "sccache")) lists scan-build as a transparent launcher, so even a plain scan-build make
    is read as make; the $(brew --prefix ...)/bin/ program prefix is a command substitution, yet the strict .txt
    has no ERROR for static-analysis (strict and allow outputs are identical)
  • repro: workflow step run: scan-build --status-bugs make on a C project with a Makefile
  • confidence: high (that it is not credited); medium (which of the two causes applies here)
pgvector/pgvector / platform-matrix, sanitizers
  • kind: UNSUPPORTED
  • actual: platform-matrix PASS "3 OS(es), 3 compiler(s)"; sanitizers FAIL "no sanitizers found"
  • expected: the matrix that matters for a Postgres extension is the server version (15-20 here, via
    ankane/setup-postgres postgres-version), and the valgrind job (ankane/setup-postgres-valgrind, check-ub: yes)
    is the ecosystem's memory/UB check; neither is known
  • evidence: .github/workflows/build.yml:11-22 matrix postgres: 20 ... 15; :27: postgres-version: ${{ matrix.postgres }}; :136-139: - uses: ankane/setup-postgres-valgrind@v1 / postgres-version: 18 /
    check-ub: yes; validator: grep -rn valgrind project_validator/ returns nothing
  • repro: unclear (new tool knowledge)
  • confidence: medium
dbt-labs/dbt-utils / ci-present
  • kind: MESSAGE
  • actual: PASS: lists .github/workflows/ci.yml and .github/workflows/create-table-of-contents.yml as CI; the strict
    run's ERRORs cascade from ci.yml's reusable workflow
  • expected: a note that ci.yml runs only on workflow_dispatch (its automatic triggers are commented out) and
    create-table-of-contents.yml never runs (on: []): the project's actual CI is CircleCI
  • evidence: .github/workflows/ci.yml:12-19: # Automatic triggers temporarily disabled while investigating ... /
    workflow_dispatch:; .github/workflows/create-table-of-contents.yml:8: on: []
  • repro: a workflow with on: []
  • confidence: medium

Found by the regression-corpus audit (235 real repositories, one or more per ecosystem profile; corpus and expected results in corpus/). Evidence is quoted from the audited checkouts at the commits pinned in corpus/projects.toml; <checkouts>/<owner>__<repo> is such a checkout.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt

Lingua principale
Python
Stelle
4
Fork
1
Merge medio
10h 41m
PR unite (30g)
79

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di cpp-best-practices/project_validator

Tutte le issue di cpp-best-practices/project_validator

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.