[R-pkg-devel] CRAN pretest: Overall checktime 14 min > 10 min

[Uwe Ligges]

Well, on incoming, we only check on two systems and the Windows timings 
will be reported in the message you receive, you can also see them when 
using the winbuilder service.

For some of the other OS/ R flavors, you can see them after they are 
published on CRAN on the check summary pagesa on CRAN, e.g. for 
Rnightlights:

https://cran.r-project.org/web/checks/check_results_Rnightlights.html

Noet that Windows typically takes much longer as some parts of the 
checks are performed for 32-bit and 64-bit.

Best,
Uwe Ligges


On 21.05.2018 18:16, Chris Njuguna wrote:
> Thanks Uwe,
> 
> I think the timeouts are helpful also in encouraging better coding 
> practices. I will try to limit my tests as described by Dirk especially 
> since I am planning to increase my code test coverage. Is it possible to 
> get the test timing breakdowns for each flavor?
> 
> Christopher Njuguna
> cell: +254 717 916 343
> cell: +254 739 956 510
> gchat: chris.njuguna
> skype: christopher.njuguna
> twitter: @chrisnjuguna
> 
> On Mon, May 21, 2018 at 6:46 PM, Uwe Ligges 
> <ligges at statistik.tu-dortmund.de 
> <mailto:ligges at statistik.tu-dortmund.de>> wrote:
> 
>     In addition to what Dirk said, I just added this experimental test
>     for CRAN incoming checks few days ago and it should not reject but
>     lead to manual inspection, this will be fixed on CRAN side shortly.
> 
>     Nevertheless: The idea is that we have timeouts for checking a
>     package and we want to be alerted of future timeout problems in
>     advance when a package is submitted.
> 
>     Best,
>     Uwe Ligges
> 
> 
> 
>     On 21.05.2018 14:06, Dirk Eddelbuettel wrote:
> 
> 
>         I can't speak to the recent increase on Windows. It may be load;
>         it may be
>         related to R 3.5.0 --- but I'd even whittle things down from 5+
>         minutes.  At
>         one point in the past we were told to aim for 1 minute, give or
>         take.
> 
>         So e.g. Rcpp has been using a scheme for _many_ years where I
>         take a cue from
>         the DESCRIPTION file. The rule I like (for my packages) is that
>         versions like
> 
>             1.2.3.1
> 
>         are "development" so I do a full test.  Whereas versions like
> 
>             1.2.4
> 
>         are "release" -- so when I only see three components, I set a
>         variable. And
>         the unit tests file can then use that variable to skip tests. 
>         This gives me
>         fine-grained control: lighter-weight tests can still run in both
>         cases. Hence
>         shorter test time for release uploads at CRAN; yet I still get
>         full tests at
>         win-builder when I send a development version.
> 
>         Dirk
> 
>