Ruby (build-mode=none) default-setup analysis fails with "no source code was seen" on pull_request events, but succeeds on push — traced to --no-calculate-baseline

Start with the Ruby build-mode=none path in tools/autobuild.sh and the referenced index-files.sh, then compare the database init and extraction logs for push and pull_request runs. Reproduce the one-file Ruby case with and without baseline calculation and verify whether pull_request extraction indexes the file and completes database finalization.

Summary

On a private monorepo using default setup with ruby enabled (alongside several other languages), the Analyze (ruby) job fails on every pull_request-triggered scan with:

CodeQL could not process any code written in Ruby. For more information, review our troubleshooting guide at
https://gh.io/troubleshooting-code-scanning/no-source-code-seen-during-build .
##[error]Encountered a fatal error while running "codeql database finalize --finalize-dataset ... /ruby". Exit code was 32

The same commit, scanned via a push event (default-setup scan of the default branch), succeeds and correctly finds/indexes the Ruby source. So this isn't "no Ruby code exists" — it's event-type-dependent behavior for the same tree.

Repro shape

• CodeQL CLI 2.26.2, codeql-action default (dynamic) setup, build-mode=none (Ruby, since it's interpreted).
• Repo has exactly one .rb file, and no Gemfile/Rakefile/.ruby-version/.gemspec anywhere else in the tree (the one file is a Homebrew Formula, so no surrounding Ruby project scaffolding).
• The .rb file is present at the head commit in both cases (verified via git ls-tree against the exact SHA each job checked out) — this isn't a stale-branch/missing-file situation.

Root cause (found via job-log diff)

Diffing the two codeql database init invocations for the same language on the two event types:

push (succeeds):

codeql database init ... --calculate-language-specific-baseline --sublanguage-file-coverage --language=ruby --codescanning-config=... --build-mode=none

Extraction then proceeds:

Scanning for files in <source-root>...
<db>: Indexing files in <source-root>...
Running command in <source-root>: [.../ruby/tools/index-files.sh, .../files-to-index<N>.list]

pull_request (fails):

codeql database init ... --no-calculate-baseline --language=ruby --codescanning-config=... --build-mode=none

Extraction stops right after the first line:

Scanning for files in <source-root>...

— no Indexing files in..., no index-files.sh invocation, no file list is ever produced. codeql database finalize then reports zero files and fails.

--no-calculate-baseline vs --calculate-language-specific-baseline --sublanguage-file-coverage is the only difference between the two invocations. Per the codeql-action changelog, skipping file-coverage collection on pull_request events is an intentional, recent (~April 2026) performance change. The CLI version info on the failing run also carries a suppressesMissingFileBaselineWarning feature flag, suggesting file-discovery and baseline/coverage computation are coupled somewhere in this path for at least the Ruby extractor under build-mode=none.

Hypothesis

For the Ruby extractor's build-mode=none autobuild (tools/autobuild.sh), file discovery for indexing appears to be driven by (or gated on) the same computation that produces the file-coverage baseline. When that computation is skipped (now the default on pull_request events), index-files.sh never runs, so the extractor indexes zero files — independent of what's actually in the checkout. This doesn't seem to affect other configured languages in the same repo (Python, JS/TS, Go, Java/Kotlin, Actions) — plausibly because they have real build/trace-based discovery or enough files/pre-existing baseline state that the gap doesn't surface the same way. It seems most likely to bite a language with very few files and build-mode=none.

Ask

• Is file-discovery for build-mode=none languages supposed to depend on baseline/coverage calculation? If not, this looks like an unintended regression from the file-coverage-on-PR change.
• Is there a documented workaround short of disabling the language entirely for default setup (which is what we're doing in the interim)?

Happy to provide additional (sanitized) log excerpts if useful — the repo itself is private, so I can't link the actual run, but the command-line diff above is copied verbatim from both jobs' logs.