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

Offen
  • Stimmt etwas nicht?
#256 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
40/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
github-actions, python, r
Bereich
ci-cd, testing

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
Python
Sterne
4
Forks
1
Ø Merge
10 Std. 41 Min.
Gemergte PRs (30 T.)
79

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cpp-best-practices/project_validator

Alle Issues in cpp-best-practices/project_validator

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.