Test build on different versions of GDAL etc

[Robinlovelace]

It would be useful for debugging purposes and reproducibility to rebuild the book regularly against the most recent releases of OSGEO packages GDAL, PROJ and GEOS (are there others?). Two main ways I can think of to do this are:

• On travis versions with +s that it's already what we use and will clearly flag issues
• By shipping more different versions of the geocompr Docker images that use the latest versions of upstream dependencies, with the +s that others may be able to use the dockerfiles for their own test purposes and that we may be able to test building the book building on these docker files, e.g. via gh-actions which supports Dockerfiles

I am not sure which one would be best and it makes me wonder if it's worth rethinking our approach to testing and Docker.

[Nowosad]

Hi @Robinlovelace,
I think with all of the pieces moving at the moment (PROJ 6+, new sf + rgdal, changes in dplyr...), we need to fix the issues step by step. My thinking right now is:

1. Fixing vignettes in https://github.com/geocompr/geocompkg
2. Adding ghactions to https://github.com/geocompr/geocompkg
3. Fixing issues in https://github.com/Robinlovelace/geocompr/
4. Adding ghactions to https://github.com/Robinlovelace/geocompr/

Let me know what you think.

Related: #480

[Robinlovelace]

I agree with that breakdown would suggest a different order of priorities:

1. Fixing issues in geocompr build - the latest version worked with recent versions of sf and OSGeo libraries
2. Fixing issues in geocompkg for sure is a priority
3. ghactions should be able to support testing on multiple set-ups

[Robinlovelace]

Heads-up @Nowosad after a few successful builds it's failing again 😢 with the following message:

Quitting from lines 851-863 (05-geometry-operations.Rmd) 
Error in CPL_transform(x, crs, aoi, pipeline, reverse) : 
  OGRCreateCoordinateTransformation() returned NULL: PROJ available?

Any ideas what's causing that? Seems related to PROJ...

https://travis-ci.org/github/Robinlovelace/geocompr/builds/673174784#L15245

[Robinlovelace]

Just saw this: #490 hopefully that fixes it, perhaps ubuntugis-unstable will ship more recent versions of PROJ in Bionic than Xenial.

[Robinlovelace]

The issue also affects the geocompkg build: https://travis-ci.org/github/geocompr/geocompkg/builds/673166325#L9754

Note that it's still building on Xenial despite that change: https://travis-ci.org/github/Robinlovelace/geocompr/jobs/673328829#L19

[Robinlovelace]

Which is surprising when reading this: https://docs.travis-ci.com/user/reference/bionic/

[Nowosad]

Probably this is our answer - https://travis-ci.community/t/bionic-builds-fail-call-xenial-solved/4899/3

[Robinlovelace]

Doesn't seem like much of an answer, more of a question, why doesn't Travis support Bionic distributions for R?

Looking at https://travis-ci.org/github/ropensci/babette/builds/672968306 it looks like the author of that post is still on Xenial in Travis. Any updates on this @richelbilderbeek ? Looks like #491 may save lots of time...

[richelbilderbeek]

@Robinlovelace: if you take a look at the the config file of that same build you see that the package is on bionic:

[Robinlovelace]

Thanks @richelbilderbeek but it still says 16.04 in the build log. I see

Build image provisioning date and time

Mon Mar 25 16:52:50 UTC 2019

Operating System Details

Distributor ID:	Ubuntu

Description:	Ubuntu 16.04.6 LTS

Release:	16.04

Codename:	xenial

Here on line 16 and below, despite the dist: bionic line in the config: https://travis-ci.org/github/ropensci/babette/jobs/672968307

[Robinlovelace]

Heads-up @Nowosad I've made some good progress towards solving this on local tests. I will push them here, which is where we should host Dockerfiles for this project I think: https://github.com/geocompr/docker

[Robinlovelace]

Just add you to the team:

[Robinlovelace]

Quick question @Nowosad, does this look like a suitable starting build matrix, with 6 options currently?:

#> [1] "default_repos"                "ubuntugis_unstable"          
#> [3] "ubuntugis_stable"             "default_repos_buildbook"     
#> [5] "ubuntugis_unstable_buildbook" "ubuntugis_stable_buildbook"

See here for my latest thinking on this: https://github.com/geocompr/docker#docker

[Nowosad]

Hi @Robinlovelace, nowosad was already taken on dockerhub, so I am jakubnowosad there - https://hub.docker.com/u/jakubnowosad

[Robinlovelace]

Ah, I'll fix that now. Heads-up, we now have the 10 different variants including default_repos, ubuntugis_stable, ubuntugis_unstable and dev version of dplyr (just added). Unfortunately the DockerHub's build system is very slow so it may take a day or so for all the tests, including 'buildbook' variants for each set-up type, to complete.

[Robinlovelace]

You're in:

[Robinlovelace]

One option is to use these pre-build Docker images as the basis of GH Actions runs:

You can run workflows on GitHub-hosted runners or self-hosted runners. Jobs can run directly on the machine or in a Docker container.

https://help.github.com/en/actions/configuring-and-managing-workflows/configuring-a-workflow#choosing-a-runner

[Nowosad]

Yep. That would be great.

[Nowosad]

Ah, I'll fix that now. Heads-up, we now have the 10 different variants including default_repos, ubuntugis_stable, ubuntugis_unstable and dev version of dplyr (just added). Unfortunately the DockerHub's build system is very slow so it may take a day or so for all the tests, including 'buildbook' variants for each set-up type, to complete.

I know we should restrict a number of created docker images (it could become a pain sometime in the future), however, would it be possible to add one new with R 4.0.0 (which should be official in about 10 days..)?

[Robinlovelace]

Possible. Suggest we wait for the Rocker team to add support for R 4.0.0 and build from rockerdev/geospatial:4.0.0 when it is available. Let me know which of the variants you think are most/least important.

[Nowosad]

@Robinlovelace, I do not know is it even possible, but maybe you can answer it - can we somehow derive GDAL, GEOS, and PROJ versions from the docker images?

[Robinlovelace]

can we somehow derive GDAL, GEOS, and PROJ versions from the docker images?

Knowing the Ubuntu version, PPA and time should be enough. The versions on the default repos will change very rarely, if at all, and I think the ubuntugis-stable and ubuntugis-unstable repos have calmed down.

We could also automate checks from inside the containers but that would be a pain. We could get the build logs to print the versions.

But I think just using the images and stating the versions when using them, e.g. after running library(sf), should be useful enough for the purpose (debugging the book, identifying issues upstream before they hit production systems and CRAN, hence adding dev dplyr which I guess will error).

[Robinlovelace]

Already generating interesting findings: the book build fails with old OSGeo versions when sf is not first re-installed as shown here:

[Robinlovelace]

Heads-up @Nowosad, good news: it seems the book builds fine on the dev version of dplyr, reproducible example shown below:

docker run -it --rm geocompr/geocompr:dplyr_dev bin/bash
Unable to find image 'geocompr/geocompr:dplyr_dev' locally
dplyr_dev: Pulling from geocompr/geocompr

...
root@e6f81d97ff3c:/# 
root@e6f81d97ff3c:/# R

R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
...
> library(dplyr)

Attaching package: ‘dplyr’

The following objects are masked from ‘package:stats’:

    filter, lag

The following objects are masked from ‘package:base’:

    intersect, setdiff, setequal, union

> packageVersion("dplyr")
[1] ‘0.8.99.9002’
> 

[Nowosad]

Great!

[Robinlovelace]

I think we can almost close this now. One thought: could we set-up a test build of the book on Windows with GH actions? Let me know if you're up for giving this a bash @Nowosad, I suspect many of the recent issues are on Windows...

[Nowosad]

@Robinlovelace I would suggest waiting on it until R 4.0 is here.

[Nowosad]

Related: r-spatial/sf#1370 (comment)

[Robinlovelace]

Heads-up @Nowosad I think we can close this now. The rstudio_devel version has R 4.0.0 (not yet built on Dockerhub), please take a look and let me know what you think: https://github.com/geocompr/docker#geocomputation-with-r-in-docker

Only remaining task: link to this new report in the Docker section in the README I think...

[Robinlovelace]

I would suggest waiting on it until R 4.0 is here.

It already is for testing and can be built with:

docker build rstudio_devel

from the docker repo. But it's probably worth keeping this issue open as a place to store issues/comments associated with this until a week or so after R 4.0.0 is officially released.

[Nowosad]

@Robinlovelace have you seen this - https://jozef.io/r922-github-actions-r-packages/. Is it useful here?

[Robinlovelace]

Not seen that, maybe useful...

[Nowosad]

Another useful blog post - https://medium.com/@skyetetra/r-docker-faster-28e13a6d241d

[Robinlovelace]

Very good to see this. I wonder to what extent we should do testing in the geocompr/docker repo and to what extent we should use GH Actions. One issue I have is that I cannot figure out how to build the book inside a Docker container with GH actions, although the previous post from jozef.io provides a pretty clear indication. Seems that just by adding

RUN install2.r --error tmap

For example we can massively reduce build times, after the next version of tmap on which the book relies is released.

[Robinlovelace]

We now test the build on the geocompr/geocompr:dev-osgeo-b image which has:

�[91mLinking to GEOS 3.8.1, GDAL 3.2.0, PROJ 7.2.0

Good enough for now? I think so so closing this for now.

[Robinlovelace]

link to the builds https://hub.docker.com/r/geocompr/geocompr/tags?page=1&ordering=last_updated