Resolve CRAN submission problems

[gothub]

From the package submission to CRAN:

For windows:

** running examples for arch 'i386' ... [94s] NOTE
Examples with CPU or elapsed time > 10s
                  user system elapsed
getSystemMetadata 1.64   1.22   11.25
** running examples for arch 'x64' ... [97s] NOTE
Examples with CPU or elapsed time > 10s
                  user system elapsed
getSystemMetadata 1.82   1.58   12.45
getChecksum       1.52   1.27   10.75

for debian:

* checking tests ... [99s/570s] ERROR
  Running ‘testthat.R’ [99s/570s]
Running the tests in ‘tests/testthat.R’ failed.
Complete output:
  > library(testthat)
  > test_check("dataone")
  Loading required package: dataone
  ── 1. Error: CNode getObject() (@test.CNode.R#40)  ─────────────────────────────
  argument 'x' must be a raw vector
  1: xmlParseDoc(rawToChar(obj), asText = TRUE) at testthat/test.CNode.R:40
  2: rawToChar(obj)

  ══ testthat results  ═══════════════════════════════════════════════════════════
  OK: 197 SKIPPED: 37 FAILED: 1
  1. Error: CNode getObject() (@test.CNode.R#40) 

  Error: testthat unit tests failed
  Execution halted

[gothub]

It appears that neither one of these problems is related to R version or platform. The first is simply services taking too long to respond, and the second I'm assuming is a service timing out and returning a null value to the call obj <- getObject(cnProd, pid) (this call works fine on all platforms I've tested, including Debian R-devel, but my test machine is on the same fast network as the servers.)

For the 'elapsed time' problem, I've put example code in 'dontrun' blocks, and for the later, a check has been added to test if the object was returned properly, i.e. is it of class 'raw'.

This is only an interim solution, as the real problem (i'm assuming) is slow services/servers, which we don't always have control over.

So, the real solution is to determine why the servers are running so slowly. Some of the services that are slowing down the checks (in URL form) are:

http://cn.dataone.org/cn/v2/object/aceasdata.3.2 http://cn.dataone.org/cn/v2/meta/doi:10.5063/F1QN64NZ

Note: after looking on Check MK for cn.dataone.org (currently cn-ucsb-1.dataone.org), it can be seen that the CPU load has been between 90-100% for the last couple of days, and could be the reason why CRAN checks are taking too long.

Either we wait to submit the dataone R package until cn.dataone.org has returned to a normal workload, or continue to remove checks/examples from running that call the CN.

[mbjones]

@gothub, I think that @nickatnceas can assign more CPU and memory to cn-ucsb-1 if that helps things. If we are maxing out, then he probably should. Even still, it would be good to ensure our R tests complete in a reasonable time. Wrapping network-dependent checks in dontrun seems like a reasonable compromise to me so long as they are being checked on Travis or another CI system, plus during our local runs of the checks.

[gothub]

I'll also discuss this with @datadavev to determine what is being done cn-ucsb-1, can it be throttled back, how long it might run and how much additional CPU or memory would be required to do the required processing and have reasonable service response time.

It is the examples in the function documentation that is causing the CRAN check problems. It would be helpful if roxygen had a tag to denote that an example shouldn't be run when CRAN is checking/running the examples. I'll have a look at the roxygen2 and devtools repos to see if this has ever been requested.

[gothub]

In commit 09fa39322f5e48a3e752104260a5db89e18f8b66, many of the roxygen '\dontrun' tags have been replaced with '\donttest', which causes the enclosed example code blocks to not be run during check(). These examples can be run however, if the argument --run-donttest is specified, for example R CMD check --as-cran --run-donttest dataone_2.1.1.tar.gz. The \dontrun tags are still used for examples for deprecated functions, or examples that require DataONE authentication.

[gothub]

With the commit 0625266e1d1f51fc215db4e3eb48064025e72c90, the 'examples' check on CRAN win-builder checks are passing consistently, i.e. running the examples in the source code doesn't exceed the CRAN limits. This was mostly achieved by adding '\donttest' blocks to examples that call the CN.