-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test cases for recreation of difficult CRAN check failures #20
Comments
@maelle (I believe you knew people who might be able to help us with this if they are willing?) |
@statnmap With all the golem and fusen problem you posted in Twitter. From #7 I created a dashboard that compared CRAN checks between two consecutive days and filtered to packages without any change in dependencies and their own version. All the history/packages that had some problem in a given day is collected in the history branch. Note that this does not take into account different R version used. For longer historical data of CRAN checks changes there was cchecksapi. |
I do have a recent example where {fusen} failed on Debian during the pre-checks: https://win-builder.r-project.org/incoming_pretest/fusen_0.4.1_20220924_231030/Debian/00check.log Before sending it to CRAN, I ran the package with The checks did not fail on any of GitHub Actions either. After that, I decided to add a |
So @statnmap from the output:
It looks like this is a race condition in a temporary file you're creating, right? |
I looked at the intermittent failures data. Since 2022-01-30 the following packages had different results within CRAN checks:
These versions might have something that cannot be checked consistently and could serve as a starting point to find packages with check failures on CRAN that are difficult to recreate locally with standard Additionally, CRAN flavors that resulted in checks not able to recreate previous results are:
|
@llrs r-devel flavors are probably a no go as a moving target, Possibly the same for patched variants. Need a span of time where the version of R used for the check variant would be constant. Also, what are the n's there? Is that times it intermittently failed? |
I took a glance at bayesQR, and it has examples, but neither tests nor vignettes, which in a sense narrows things down somewhat. |
@gmbecker This warning message is expected. I just couldn't capture it in the unit test because I already capture the if (!isTRUE(overwrite)) {
cli::cli_alert_danger(
paste(
"Aborting fusen project creation.",
"Set `create_fusen(overwrite = TRUE)` to avoid a stop."
)
)
stop("Could not create fusen project", call. = FALSE)
} What fails here is this line: https://github.com/ThinkR-open/fusen/blob/40cd8df7ca36b4e11efb6ec691cdd50ba38ed908/tests/testthat/test-inflate-part1.R#L182 |
@llrs I do not see the WARN coming from Bioconductor installation problems. |
@gmbecker I tried tracking the r-devel version but it is not reported on the summary and I didn't parse it from all the checks. But I did extract it from a single package check and extrapolated from there. But this is one of the suggestions I had for the CRAN team: provide in The n is indeed number of status changes not driven by dependencies changes, packages updates or R version changes. It counts any change including from OK to NOTE or from NOTE to OK. @statnmap I do not focus on which is the cause of the intermittent failures. But missing Bioconductor dependencies is a common message (Error, warning or note depending on the type of dependency): I think you can capture warnings and errors on the same test via a nested call: |
Now that we have the scripts used by CRAN (#17) We need examples of packages with check failures on cran that are difficult to recreate locally with standard
R CMD check
usage in order to see whether using the specific CRAN checks is helpful in exposing additional issues that submitted packages are running afoul of.Please add examples of such to the comments
@jeroen
The text was updated successfully, but these errors were encountered: