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.
Debugging Procedure
Check that the API is online
The following code will confirm that the API is online, by returning a single numeric value:
httr::GET ("http://<ip-address>:8000/mean") |>
httr::content ()
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:
roreviewapi::check_issue_template (orgrepo = "ropensci/software-review",
issue_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 editor_check()
function.
Enter the
roreviewapi
Docker image viadocker run -it --rm roreviewapi /bin/bash
and start R.Set
repourl <- <url>
and runpath <- roreviewapi::dl_gh_repo (repourl)
to download a clone of the repository.Type
os <- "ubuntu"
andos_release <- "20.04"
.Run
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 runningremotes::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 fororgrepo
andissue_num
can be used to first confirm that the checks look okay before posting them toropensci/software-review
.
These steps can be run in two code chunks, the first directly in the shell environment of the Digital Ocean droplet:
docker run -it --rm roreviewapi /bin/bash
R
And the second within the R environment:
repourl <- "https://github.com/org/repo" # replace with actual org/repo values
path <- roreviewapi::dl_gh_repo (repourl)
os <- "ubuntu"
os_release <- "20.04"
p <- roreviewapi::pkgrep_install_deps (path, os, os_release)
checks <- pkgcheck::pkgcheck(path)
out <- roreviewapi::collate_editor_check (checks)
orgrepo <- "ropensci/software-review" # or somewhere else for testing purposes
out <- roreviewapi::post_to_issue (out, orgrepo, issue_num)