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

Aperta
  • Qualcosa non va?
#256 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
40/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github-actions, python, r
Ambito
ci-cd, testing

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Python
Stelle
4
Fork
1
Merge medio
10h 41m
PR unite (30g)
79

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di cpp-best-practices/project_validator

Tutte le issue di cpp-best-practices/project_validator

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.