vignettes/debugging.Rmd
debugging.RmdThe main API endpoint for the Digital Ocean server is the editorcheck, called by the ropensci-review-bot on every submission, and also manually (re-)triggered by the command @ropensci-review-bot check package. This vignette describes procedures which may be used to debug any instances in which package checks fail.
Most failures at the server end will deliver HTTP error codes of “500” like this example. This code may indicate that the server is currently unavailable, which will arise once per week during rebuild and redeploy processes, scheduled every Monday at 23:59 UTC. If a submission happens to be roughly at this time, the recommended procedure is to wait at least an hour before manually trying @ropensci-review-bot check package. Other 500 codes should be reported straight to maintainers of the check system, currently to @mpadge and @noamross as respective first and second points of contact. This vignette describes the procedures they would follow to debug any problems.
Debugging generally requires stepping through the code as called by the main editorcheck endpoint, and into the editor_check() function called by the endpoint as a background process.
The following code will confirm that the API is online, by returning a single numeric value:
The log entries are illustrated in the endpoints vignette, and can be used to ensure that all variables were successfully delivered in the request. Any missing or malformed variables most likely indicate problems with the submission template. These should be caught by the initial call make by the editorcheck function to the check_issue_template() function. Potential issues can be debugged by calling that function locally:
That should return an empty string with an additional attribute, "proceed_with_checks", which should be TRUE. Any other return value indicates an issue with the submission template, for which the return value should contain text describing the problem.
This and the following checks are components of the editor_check() function called by the main endpoint as a background process, the first step of which is to identify and install system dependencies. This step is error prone, as is also the case on all CRAN machines. A final step of the check is to identify any packages which were unable to be installed, and to post a list of these directly in the submission issue. Such instances should generally be temporary, and fixed by forthcoming CRAN updates. These happen because of temporary breakages in one package which lead to other packages becoming unable to be installed from CRAN, with these temporary breakages in turn generally arising because of changes to external (non-R) system libraries. If any notified inabilities to install packages adversely affect final check results, debugging may require manually running checks on the Digital Ocean server, as described in the final section below.
The system output and error logs from checks for a specified package are accessible from the stdlogs endpoint, which requires the single parameter of the repourl of the repository being checked. Logs are kept for the latest git head, and are accessible if and only if the latest GitHub commit matches the points at which the logs were generated. In those cases, the return value may offer useful diagnostic insights into potential problems either with submitted packages, or the check system itself.
If all else fails, checks can be manually run directly from the Digital Ocean server, and sent straight to the relevant issue. The following procedure describe how, generally following the main editor_check() function.
roreviewapi Docker image via docker -it --rm --entrypoint /bin/bash roreviewapi and start R.repourl <- <url> and run path <- roreviewapi::dl_gh_repo (repourl) to download a clone of the repository.os <- "ubuntu" and os_release <- "20.04".p <- roreviewapi::pkgrep_install_deps (path, os, os_release). The value, p, will list any packages which were unable to be installed. These will then need to be manually installed, generally through finding the remote/dev URLs for the packages, and running remotes::install_github() or similar. Note that successful installation may only be possible in a particular order, and in the worst cases may be a process of trial and error.checks <- pkgcheck::pkgcheck(path), during which diagnostic output will be dumped directly to the screen.out <- roreviewapi::collate_editor_check (checks).out <- roreviewapi::post_to_issue (out, orgrepo, issue_num). Alternative values for orgrepo and issue_num can be used to first confirm that the checks look okay before posting them to ropensci/software-review.