Re: R package CI test failures
On Thu, Apr 28, 2016 at 10:42:45AM +0200, Gordon Ball wrote:
> > me. My only idea is to rather use
> >
> > pkg=r-bioc-`echo $oname | tr '[A-Z]' '[a-z]'`
> >
> > and so I try this even if I think this is equivalent.
>
> Hmm, yes. I can't obviously see why this fails. (Aside - `tr A-Z a-z`
> works just as well, but as far as I can see both are valid syntax).
Anyway - I think those packages I uploaded for other reasons (new
upstream version) and added quotes are now passing the test so I'll fix
this.
> However, since the working dir for the test is the root of the extracted
> source package, we should be able to extract the R and debian package
> names directly rather than hardcoding or deriving them:
>
> rpkg=$(grep-dctrl -s Package -n '' DESCRIPTION)
> dpkg=$(grep-dctrl -s Package -n '' debian/control)
>
> and in fact, skip finding tests and vignettes in the installed
> filesystem and just find them in the source package: tests/*.R ;
> vignettes/*.Rnw - in which case we don't need to know the package R or
> debian names.
I confirm that if you use the script for CI *only* this would work
nicely. However, I consider it a good idea to provide the user with
some test case / example use and thus I always put the script into
/usr/share/doc/<pkgname> where grep-dctrl does not work. On the other
hand I could check the directory name if all other means to calculate
the package name might fail.
> As discussed in the autodep8 thread, it would definitely be good to
> extend the implicit test to running tests/*.R and vignettes/*.Rnw/md,
> and clearly this would avoid duplication of a large number of similar
> run-unit-test files (although I think we should wait a while and see
> what happens with the simple autodep8 test already added and see how
> that works out first).
+1
> > That's even more strange. I like to just insert the original CRAN
> > spelling and calculate the Debian package from mit but tr does not
> > seem to do a reliable job and I wonder why.
>
> The version with quotes in r-bioc-cummerband now seems to work (or at
> least, it gets further and finds a different error -
> vignettes/cummeRbund-example-workflow.Rnw appears not to load the
> library before using functions from it, which I suspect is a package bug).
I need to check this ...
> >> r-bioc-aroma.light: attempts install.packages
> >
> > I don't understand this one.
>
> The culprit appears to be R.utils::use(packagename) buried in various
> functions. It attempts to install if the package isn't available. It
> fails trying to load/install princurve (unpackaged, in the Suggests field).
Just found this a couple of minutes ago and uploaded a fix (hack)
stripping the test past the attempt to use princurve.
> >> r-bioc-genomicalignments: min_overlap_score bug
> >> r-bioc-genomicranges: min_overlap_score bug
> >
> > I don't understand this type.
>
> Not sure, but this has disappeared in today's resuults. I suspect some
> of the bioconductor packages might need tighter dependencies on each other.
Something remains wrong here. I'll upgrade to latest version and
check again.
> >> r-cran-dplyr: R version mismatch (built under 3.3.0)
> >
> > Huhu, what's that???
>
> It looks like this is not the cause of failure, just a warning (the
> immediate failure in this case is that the package doesn't depend on
> r-cran-rcpp (necessary to load the namespace, not just run tests).
> However, it also warns that it was built by R 3.3.0 - presumably a
> binary upload by someone with an experimental R package on their system.
> The package is loadable at least after r-cran-rcpp is installed.
Fixed in recent upload.
> >> r-cran-futile.logger: error in run-unit-test script
> >
> > What kind of error? Runs fine for me if I call it directly.
> >
>
> The error in the CI run is "find: missing argument to -exec". Maybe
> missing a trailing \; ?
Grrrr, you are right. Fixed.
> >> r-cran-lambda.r: error in run-unit-test script
> >
> > What kind of error? Runs fine for me if I call it directly.
> >
> Same as r-cran-futile.logger above it appears. Whether it errors is
> maybe sensitive to the CWD it is run from since it does `find .`?
Fixed cut-n-pasto.
> >> r-cran-magrittr: error in run-unit-test script
> >
> > What kind of error? Runs fine for me if I call it directly.
> >
>
> find -exec again.
Fixed cut-n-pasto
> >> r-cran-r.methodss3: bad subsitution in run-unit-test
> >
> > Waiting for confirmation that quotes in tr call are helpful.
Fixed in new upstream version upload.
> >> r-cran-r.utils: error in run-unit-test
> >
> > What kind of error? Runs fine for me if I call it directly.
> >
>
> Looks like the delete at the end (rm -f $ADTTMP/*) fails since some of
> the targets are directories (missing -r)
Ahhh, stupid. Fixed in recent upload of new upstream version.
> And thanks for fixing so many of these so quickly
You are welcome. I'm keen on getting the tests really functional
so its a pleasure to support your attempt.
> - hopefully it'll look
> in much better shape in a few days and we can see if CI is actually
> doing its job and identifying some real errors.
Yes.
> I'll have a better look at the "?" ones.
Thanks again
Andreas.
--
http://fam-tille.de
Reply to: