Hi,
I'm trying to implement a CI pipeline (using gitlabCI) for some custom packages I have written that have plumber API's nested within them, following the approach laid out in https://github.com/sol-eng/plumbpkg.
The tests of the style
**test_that("API is alive", {
expect_true(api1$is_alive())
expect_true(api2$is_alive())
})**
work ok locally. Additionally, when I build out my CI pipeline for a vanilla version of my package that just contains a basic API that echoes back an input message, the test work ok on the system, with the following gitlab-ci.yaml (please forgive any inefficient yaml, I'm trying my best 
)
image: r-base:3.6.2
stages:
- check
variables:
R_LIBS_USER: "$CI_PROJECT_DIR/ci/lib"
CHECK_DIR: "$CI_PROJECT_DIR/ci/logs"
BUILD_LOGS_DIR: "$CI_PROJECT_DIR/ci/logs/plumbertestingtest.Rcheck"
test:
stage: check
script:
- apt-get update --allow-releaseinfo-change && apt-get install -my gnupg libssl-dev libcurl4-openssl-dev libssh2-1-dev libxml2-dev
- apt-get install -y make libicu-dev pandoc libxml2-dev libsodium-dev
- mkdir -p $R_LIBS_USER $BUILD_LOGS_DIR
- R -e 'install.packages(c("lintr", "devtools", "roxygen2"))'
- R -e 'devtools::install_deps(dep = T, lib = Sys.getenv("R_LIBS_USER"))'
- R -e 'devtools::check(check_dir = Sys.getenv("CHECK_DIR"))'
- R -e 'if (length(devtools::check_failures(path = Sys.getenv("BUILD_LOGS_DIR"), note = FALSE)) > 0) stop()'
- R -e 'devtools::load_all(); if (length(lintr::lint_package()) > 0) stop()'
for simplicity sake I've stripped out some of the rules, but the essential structure is there.
Ultimately, I have some more complicated packages that will follow the rough outline of the above CI, but have more dependencies, so I looked to try and use a different base docker image that would reduce the time that the pipelines took to build.
I started by jumping to using the rocker/tidyverse base image plus a few dependencies that this didn't quite cover, but that caused the test to fail
── 1. Failure: API is alive (@test-test-plumber.R#19) ─────────────────────────
api1$is_alive() isn't true.
── 2. Error: echo endpoint works (@test-test-plumber.R#25) ────────────────────
Failed to connect to localhost port 8000: Connection refused
Backtrace:
1. httr::GET(root_path, port = 8000, path = "echo", query = list(msg = "Hello World"))
2. httr:::request_perform(req, hu$handle$handle)
4. httr:::request_fetch.write_memory(req$output, req$url, handle)
5. curl::curl_fetch_memory(url, handle = handle)
══ testthat results ═══════════════════════════════════════════════════════════
[ OK: 1 | SKIPPED: 0 | WARNINGS: 0 | FAILED: 2 ]
1. Failure: API is alive (@test-test-plumber.R#19)
2. Error: echo endpoint works (@test-test-plumber.R#25)
Error: testthat unit tests failed
I worked it back to having a similar approach to my version with r-base image, but using rocker/r-ver instead which seems to be the root image that the rocker/tidyverse one is built upon, that looked a bit like this
image: rocker/r-ver:3.6.2
stages:
- check
variables:
R_LIBS_USER: "$CI_PROJECT_DIR/ci/lib"
CHECK_DIR: "$CI_PROJECT_DIR/ci/logs"
BUILD_LOGS_DIR: "$CI_PROJECT_DIR/ci/logs/plumbertestingtest.Rcheck"
test:
stage: check
script:
- apt-get update --allow-releaseinfo-change && apt-get install -my gnupg libicu-dev pandoc libsodium-dev libssl-dev libcurl4-openssl-dev libssh2-1-dev libxml2-dev zlib1g-dev libgit2-dev
- mkdir -p $R_LIBS_USER $BUILD_LOGS_DIR
- R -e 'install.packages(c("lintr", "devtools", "roxygen2"))'
- R -e 'devtools::install_deps(dep = T, lib = Sys.getenv("R_LIBS_USER"))'
- R -e 'devtools::check(check_dir = Sys.getenv("CHECK_DIR"))'
- R -e 'if (length(devtools::check_failures(path = Sys.getenv("BUILD_LOGS_DIR"), note = FALSE)) > 0) stop()'
- R -e 'devtools::load_all(); if (length(lintr::lint_package()) > 0) stop()'
which gives the same error as above, so I'm currently in the process of going through and adding each additional dependency one at a time on to my r-base version to see if I can identify which one is casing the API test to fail on the CI runner.
I know I can wrap the api test in a skip_if_not(interactive()), which gets the pipeline to pass, but that feels more like ignoring the issue rather than fixing it. I'll keep going with my testing, but if anyone has run in to this issue before, or can shed any light on the issue, that would be greatly appreciated