Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#4,078 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Pouca atividade
Stack de tecnologia
github-actions, ruby, typescript
Domínio
ci-cd, security

Direção de pesquisa

Comece pelo caminho Ruby build-mode=none em tools/autobuild.sh e pelo index-files.sh referenciado; em seguida, compare os logs de inicialização e extração do banco de dados para as execuções de push e pull_request. Reproduza o caso Ruby de um único arquivo com e sem o cálculo de baseline e verifique se a extração de pull_request indexa o arquivo e conclui a finalização do banco de dados.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
1.7k
Forks
495
Merge médio
1d 2h
PRs com merge (30d)
47

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de github/codeql-action

Todas as issues de github/codeql-action

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.