Debugging the package check API
The 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.
Check that the API is online
The following code will confirm that the API is online, by returning a single numeric value:
Check log of recent requests
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:
::check_issue_template (orgrepo = "ropensci/software-review", roreviewapiissue_num = <issue_num>)
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.
Check installation of system dependencies
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.
Check system output and error logs
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.
Manually running checks
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
- Enter the
roreviewapiDocker image via
docker -it --rm --entrypoint /bin/bash roreviewapiand 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.
- Finally generate the main checks by running
checks <- pkgcheck::pkgcheck(path), during which diagnostic output will be dumped directly to the screen.
- Convert checks to markdown format by running
out <- roreviewapi::collate_editor_check (checks).
- Finally, post the checks to the desired issue with
out <- roreviewapi::post_to_issue (out, orgrepo, issue_num). Alternative values for
issue_numcan be used to first confirm that the checks look okay before posting them to