Skip to content

Ci/codeql manual build - #7

Draft
asonje wants to merge 4 commits into
mainfrom
ci/codeql-manual-build
Draft

Ci/codeql manual build#7
asonje wants to merge 4 commits into
mainfrom
ci/codeql-manual-build

Conversation

@asonje

@asonje asonje commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Description

Use CodeQL manual build mode for c-cpp

Related Issues

Type of Change

  • Bug fix
  • New feature
  • Refactor / code cleanup
  • Documentation update
  • Test addition or update
  • Build / CI change

Pre-Merge Checklist

Build

  • make completes without errors or warnings
  • make install completes successfully

Tests

  • If this PR introduces no new behavior: existing regression tests (make installcheck) and TAP tests (test/t/) pass with no failures
  • If this PR introduces new behavior: test cases covering it were added to test/sql/ and/or test/t/

Documentation

  • Relevant docs under docs/ updated if architecture or usage changed

Testing Notes

@asonje
asonje requested a review from a team August 13, 2026 21:48
asonje added 2 commits August 13, 2026 14:49
The svs extension only compiles against PostgreSQL, SVS and pgvector
headers, so build-mode: none left CodeQL extracting src/*.c with no
postgres.h, no SVS C API and no pgvector vector.h -- macros, typedefs
and struct layouts all unresolved.

Switch c-cpp to build-mode: manual and build the extension under the
tracer with the environment the build guide already documents:
docs/build_guide/config supplies PG_CONFIG and SVS_INSTALL_DIR, which
are passed to make as the Makefile expects.

The three dependency builds (install_postgres.sh, build_svs.sh,
build_pgvector_vanilla.sh) run before codeql-action/init so the tracer
wraps only this repository's make; running them afterwards would extract
PostgreSQL and the SVS C++ library into the database as well. Their
output is cached on the build scripts' hash, since a cold build of
PostgreSQL 18 plus the SVS library dominates the job.

Signed-off-by: Olasoji <olasoji.denloye@intel.com>
Signed-off-by: Olasoji <olasoji.denloye@intel.com>
@asonje
asonje force-pushed the ci/codeql-manual-build branch from c2517b0 to 657c06d Compare August 13, 2026 21:50
asonje added 2 commits August 13, 2026 15:46
The CodeQL job failed in build_svs.sh with

    'MemoryBreakdown' in namespace 'svs::index::vamana' does not name a type

With SVS_RUNTIME_ENABLE_LVQ_LEANVEC=ON, bindings/c fetches a prebuilt SVS
archive and compiles against that archive's headers rather than the
adjacent include/. Outside GCC [11.2, 11.3) -- every Ubuntu runner -- the
archive it picks is the v0.4.0 release, whose headers predate
MemoryBreakdown, while bindings/c on dev/c-api calls
get_memory_breakdown().

Pinning SVS_URL does not help here: the only published archive carrying
the type is the LTO variant, and bindings/c links svs::svs_static_library,
whose LTO bytecode requires GCC 11.2 exactly. Building from the SVS source
tree instead compiles against local headers that match the bindings, with
no download and no ABI pin.

This costs the analysis nothing. The flag is a PRIVATE compile definition
of the svs_c_api target, and the installed C API header has no LVQ/LeanVec
ifdefs, so the symbols svs_wrapper.c uses stay declared and the extension
compiles identically. Only runtime lvq/leanvec index creation is affected,
and the job never loads the library. Revert to ON once SVS is fixed.

SVS_LVQ_LEANVEC is a config knob defaulting to ON, so local builds are
unchanged; the workflow overrides it and folds the value into the cache
key. build_svs.sh now wipes the build directory first, because SVS_URL is
a CACHE STRING and the fetched tree persists in _deps/svs-src, which would
otherwise pin the previous setting and make the change look inert.

Signed-off-by: Olasoji <olasoji.denloye@intel.com>
SVS_INSTALL defaulted to svs_install_public and the guard's error told you
to run build_svs_public.sh. Neither exists anywhere in the repository, so a
bare 'make' failed and its advice was a dead end. Point both at what the
build guide actually produces, and correct the same stale default quoted in
docs/dev/ARCHITECTURE.md.

build_pgvector_vanilla.sh and build_svs_extension.sh were committed mode
644 while their four siblings are 755, so the ./script invocations in
docs/build_guide/README.md failed with Permission denied. build_all.sh was
unaffected -- it calls them via bash.

Signed-off-by: Olasoji <olasoji.denloye@intel.com>
@asonje
asonje marked this pull request as draft August 24, 2026 21:05
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