Skip to content

Honour paths-ignore when selecting CDS compilation targets#389

Merged
data-douser merged 4 commits into
advanced-security:mainfrom
mihai-herda-SAP:cds_compile_paths_ignore
Jun 19, 2026
Merged

Honour paths-ignore when selecting CDS compilation targets#389
data-douser merged 4 commits into
advanced-security:mainfrom
mihai-herda-SAP:cds_compile_paths_ignore

Conversation

@mihai-herda-SAP

Copy link
Copy Markdown
Contributor

Honour paths-ignore when selecting CDS compilation targets

The CDS extractor was only partially honouring paths-ignore from the CodeQL config:

  1. determineCdsFilesToCompile() returned the standard CAP directories (db/, srv/, app/) as compilation targets based purely on existsSync() checks, never consulting paths-ignore. A directory whose .cds files were all excluded was still being handed to the CDS compiler. (The other two branches — root-level files and per-file fallback — were already correct, since they derive from project.cdsFiles, which is filtered upstream by determineCdsFilesForProjectDir().)

  2. When every .cds file in the source was paths-ignored, the dependency graph correctly ended up empty and the extractor entered the no-projects branch in cds-extractor.ts. That branch unconditionally logged two ERROR lines and ran a diagnostic re-glob that ignored paths-ignore entirely, so an intentional full exclusion looked identical to a real project-detection bug.

When a project has standard CAP directories (db/, srv/, app/),
determineCdsFilesToCompile() returned them as compilation targets
based solely on existSync() checks, ignoring paths-ignore from the
CodeQL config. The other two branches (root-level files and per-file
fallback) were already correct because they derive from
project.cdsFiles, which determineCdsFilesForProjectDir() filters
upstream.

Drop a CAP directory from the targets only when every .cds file
under it has been filtered out by paths-ignore (i.e. no entry in
project.cdsFiles lives under that directory). Partially-covered
directories are still compiled, matching the project convention that
paths-ignore should not change compiler input granularity unless a
target is fully covered.
When every .cds file in the source tree is filtered out by
paths-ignore, the dependency graph correctly ends up empty and the
extractor enters the no-projects branch. That branch unconditionally
logged two ERROR lines and ran a diagnostic re-glob that ignored
paths-ignore entirely, so an intentional full exclusion looked
identical to a real project-detection bug.

Apply paths-ignore to the diagnostic glob and split the no-projects
branch into three cases:

  - no .cds files in the tree (INFO, unchanged)
  - .cds files exist but all are paths-ignored (INFO, new message)
  - .cds files survive paths-ignore but no project was detected
    (ERROR, unchanged — this is a real bug)

The early-exit flow (addNoCdsProjectsDiagnostic + handleEarlyExit)
is unchanged; only the log output differs.

@data-douser data-douser left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

LGTM!

Related to but not blocking this PR, I created tracking issue #390 for what I think may be a gap in the paths-ignore behavior of the CDS extractor. If the index.cds -> model.cds.json scenario (described in that issue) isn't a real concern / problem, then we can just close that issue.

@data-douser data-douser merged commit 397aaa8 into advanced-security:main Jun 19, 2026
16 checks passed
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.

2 participants