Trigger rerunning tests on master whenever the container gets rebuilt

[hlapp]

Changes in containers on Docker Hub that the rpopgen container depends on are set to trigger a rebuild of the rpopgen container. When that happens, packages are installed into the container with their latest versions (on CRAN or Github, depending on what the Dockerfile says), which may bring API changes compared to when the tests were last run (and presumably succeeded).

Whether such API changes necessitate fixes in the Rmarkdown code snippets will only be known when the tests are rerun. If a contributor branches off, they take the potential issues into their branch, potentially dooming the test run on their build until the necessary fixes are included (which requires either advanced Git commands such as rebasing or cherry-picking, or cumbersome workarounds). Therefore, to be able to act on such issues before it hits contributors, the tests on master would need to be automatically rerun whenever the container on Docker Hub is rebuilt.

See #182 for a case in point.

[zkamvar]

One issue that definitely will arise is the fact that our attempt at a unifying git framework (git2r), currently does not have methods for cherry-pick or rebase. That being said, updating via merge, while it does create unnecessary commits, it will still work for the majority of submissions.

[zkamvar]

I wonder if we could use the Docker build to trigger a commit that, say, changes the date in the DESCRIPTION file on the master branch, effectively triggering a rebuild.