revive/rework CI

[jangorecki]

Shortly after (or even for the) 1.15.0 we should try revive/rework our CI, so PRs can be well tested, for different platforms, R versions, and code coverage.

Tests should cover:

• testing r-devel, r-release, r-oldrel
• testing stated R version
• testing linux, mac, windows
• testing vanilla R (having only base R packages installed)
• strict 0 NOTEs from R CMD check in a tailored job (using flags like _R_CHECK_CRAN_INCOMING_TARBALL_THRESHOLD_)
• testing for compilation warnings

Artifacts should cover:

• source package
• binary packages
• R repository
• documentation in pkgdown
• documentation base R html
• docker images anyone uses them? installing data.table is so easy and fast that I don't think we save a lot of effort

[tdhock]

I do not use data.table docker images (I did not know we had them) but I have used R-hub docker images in the past for testing other R packages.

[eddelbuettel]

docker images anyone uses them?

If you start from 'ubuntu: latest' as an image you then stick in container like r2u which helps once either your package is 'expensive' or all the test dependencies are. The following is from a GH Actions yaml file of mine

    runs-on: ubuntu-latest
    container:
      image: rocker/r2u:latest

and you can of course stick other containers (rhub, ...) in as needed too.

[jangorecki]

We already publish docker images from GLCI but because DT doesn't have dependencies and compiles fast there is not that much need like many other pkgs

[eddelbuettel]

Yup, all good, and it's a good spot to be in. But sometimes you want to, say, test reverse dependencies and getting them quick and easily is a bonus.

This bonus switch to an existing container in an action is sometimes I learned only this year (or last?) after sometimes having done the requivalent of a partial container setup in an action. So given the question above it felt like somethings worth sharing. Feel free to delete the posts if you think they are noise.

Looking for to data.table releases. It's been a while. So thanks for getting back to it!

[jangorecki]

Bringing back CI to life uncovered couple issues

• encoding test 2194.7 not portable #5484 - vanilla test job
• compilation warning: chmatch.c argument 1 range exceeds maximum object size #5760 - two jobs that tests for compilation warnings rel-lin and dev-cran-lin
• tests failures due to complex NA #5748 - all dev jobs
• Remove curl from suggests #5749 - vanilla test job
• memtest results not longer produced #5764 - originally in vanilla test job, now attempted to move to rel-lin

for now workarounds in CI will be either extra apt-get install or allow_failures: true

[jangorecki]

An alternative solution that I am thinking about is to set GLCI to run only once a day, rather than on every commit (in 15min git pull intervals). That will surely fit into free plans limit (and let us extend for more tests jobs and macosx builds to produce macosx binaries).

We could then set all test jobs as allow_failures: true so release process will not be blocked.

And at the same time extend, slightly, our GLCI, from which we are getting feedback on each PR.

[jangorecki]

observed on gcc job

* checking compilation flags used ... NOTE
Compilation used the following non-portable flag(s):
  ‘-Wunused-result’

need to remove some previously used flags then