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

Ouverte
  • Quelque chose ne va pas ?
#256 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
40/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
github-actions, python, r
Domaine
ci-cd, testing

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
Python
Étoiles
4
Forks
1
Merge moyen
10 h 41 min
PR mergées (30 j)
79

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cpp-best-practices/project_validator

Toutes les issues de cpp-best-practices/project_validator

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.