R: tests/*.R scripts run by R CMD check are not tests (data.table), sanitizer images (rocker/r-devel-san) are the R way to run ASan/UBSan, styler on issue_comment is not a gate

Aberta
  • Algo errado?
#256 0 comentários 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
40/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
github-actions, python, r
Domínio
ci-cd, testing

Direção de pesquisa

The three R rules live in ecosystems/r.py: the _styler check around lines 124-137 (it must consider the workflow trigger, not just the commit), the R_TEST_FILES.path regex (it must also accept tests/*.R scripts), and the sanitizer detection (it must recognise *-san and rocker/r-devel-san images). Start by reading those rules and the corpus entries for testthat, ggplot2 and data.table in corpus/. Done when those expectations match the corpus results without regressing the testthat and tinytest layouts.

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

Descrição

data.table has one of the largest R test suites (inst/tests/*.Rraw driven by tests/*.R, which R CMD check runs by definition) → FAIL "no tests found (testthat or tinytest files)". Its two GitLab jobs run the check under R built with -fsanitize=address,undefined (rocker/r-devel-san) → "no sanitizers found". testthat and ggplot2 PASS "CI enforces the styler style" though styler runs only in a /style issue-comment job that no push or PR triggers.

Evidence from the corpus audit

r-lib/testthat, tidyverse/ggplot2 (and tidyverse/dplyr) / code-formatting
  • kind: FALSE_POSITIVE
  • actual: PASS (R): "CI enforces the styler style"
  • expected: FAIL/WARN for testthat and ggplot2: styler runs only in the style job of pr-commands.yaml, which is triggered by a maintainer typing /style in a PR comment (issue_comment), so no push or pull request is ever checked; for dplyr the PASS is right but should credit air (format-suggest.yaml runs air format . on every pull_request_target and fails through reviewdog/action-suggester with fail_level: error), not styler.
  • evidence: testthat .github/workflows/pr-commands.yaml:52: if: ${{ github.event.issue.pull_request && (github.event.comment.author_association == 'MEMBER' || ...) && startsWith(github.event.comment.body, '/style') }}, :73: run: styler::style_pkg(), followed by git commit -m 'Style'; the workflow's only trigger is on: issue_comment: types: [created]. ggplot2 pr-commands.yaml:69,73 identical; ggplot2 has air.toml but no job runs air. Validator: ecosystems/r.py:124-137 (_styler: "it enforces the style where the job fails on git diff --exit-code or commits the changes") counts the commit without looking at the job's trigger.
  • repro: the r-lib pr-commands.yaml example (on issue_comment, /style guard, styler::style_pkg() + git commit) as the only workflow touching styler; expect no formatting enforcement.
  • confidence: medium (the documented rule is applied as written; the rule itself is what is wrong)
Rdatatable/data.table / tests-run
  • kind: FALSE_NEGATIVE
  • actual: FAIL: R: no tests found (testthat (tests/testthat/test-.R) or tinytest (inst/tinytest/test_.R) files)
  • expected: PASS: data.table has one of the largest R test suites (22,016-line inst/tests/tests.Rraw plus 11 more .Rraw files) run by tests/*.R scripts, which R CMD check executes by definition (every tests/*.R file is a test); CI runs R CMD check in R-CMD-check-occasional.yaml and .gitlab-ci.yml and check-r-package in R-CMD-check.yaml.
  • evidence: tests/main.R:2-4: require(data.table) / test.data.table() # runs the main test suite of 5,000+ tests in /inst/tests/tests.Rraw; tests/ also holds S4.R froll.R nafill.R optimize.R programming.R types.R ...; inst/tests/tests.Rraw (22016 lines). Validator ecosystems/r.py R_TEST_FILES.path: (?:^|/)(?:tests/testthat/test[-_][^/]+|inst/tinytest/test_[^/]+)\.[Rr]$ recognises only testthat and tinytest layouts.
  • repro: DESCRIPTION, tests/main.R containing stopifnot(foo::f() == 1), workflow with r-lib/actions/check-r-package@v2; expect tests found (R CMD check runs tests/*.R).
  • confidence: high
Rdatatable/data.table / sanitizers
  • kind: UNSUPPORTED
  • actual: FAIL: no sanitizers found; enable AddressSanitizer, UndefinedBehaviorSanitizer
  • expected: PASS (or at least a mention): two GitLab CI jobs run the whole check under R builds compiled with -fsanitize=address,undefined (clang and gcc), using the R community's standard approach of a prebuilt sanitizer image (rocker/r-devel-san, rhub/*-san, here the project's own r-devel-clang-san/r-devel-gcc-san), and fail the job on sanitizer output.
  • evidence: .gitlab-ci.yml:220-222: test-lin-dev-clang-san: ... image: registry.gitlab.com/rdatatable/dockerfiles/r-devel-clang-san; :227: LSAN_OPTIONS: "suppressions=$CI_PROJECT_DIR/.dev/lsan.supp"; :235: # fail if R CMD check had failed or if sanitizer output found; :238-240 the gcc twin; .ci/README.md:16-17 documents both as clang -fsanitize=address,undefined. The flags live in the image, so only the image name (*-san, rocker/r-devel-san, rocker/r-devel-ubsan-clang) is visible.
  • repro: .gitlab-ci.yml job with image: rocker/r-devel-san running R CMD check; expect sanitizers recognised (ASan+UBSan) for the R package's native code.
  • 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

Linguagem predominante
Python
Estrelas
4
Forks
1
Merge médio
10h 41min
PRs com merge (30d)
79

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

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 cpp-best-practices/project_validator

Todas as issues de cpp-best-practices/project_validator

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

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