Support Term?

[eitsupi]

With the release of R 4.2.3, we finally have more versions built than the number of GitHub Actions parallel execution workflows.

I don't think it is a sustainable approach to keep increasing the number of builds, so I am wondering if it is possible to stop building images that are considered unimportant (e.g. not the final version of X.Y like R 4.0.1).

[eddelbuettel]

Coincidentally, what is that number?

[eitsupi]

what is that number?

20
https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits

[cboettig]

yup, building just the latest minor version (i.e. 4.1.3, but not other 4.1.x) seems reasonable?

[eitsupi]

For now, would the following looks good?

• Last 2 patch versions (Required to freeze CRAN dates)
• All patch versions associated with the last 2 minor versions (release and oldrel)
• All minor versions R >= 4.0

The number of minor versions will eventually need to be limited, but for now I think it makes sense to support all versions since R 4.0.

[eitsupi]

Related to #776, I think it is time to revisit this.

In particular, I am wondering about the dealing with images that contain Python packages.

1. Do you need cuda-based images other than the latest?
2. Do we need to repeat builds of previous binder images?

I would like to move the cuda based images and the binder to extra and stop all builds except the latest two.
(Two are needed because CRAN and CRAN are not fixed until one version before the latest.)

In addition, I would like to remove Dockerfiles prior to 4.2.0, as it would be difficult to migrate all past Dockerfiles to the new architecture.

@cboettig Thoughts?

[eddelbuettel]

What about keeping 'max(z) in x.y.z' to keep, say, 4.2.3 and 4.3.3?

[eitsupi]

I think it makes sense to support the two latest minor versions, consistent with the checks on CRAN, and I believe Docker Official Images also continues to build the versions that are normally supported.
(I'm not sure if the two minor versions of R can be considered "supported" though)

[cboettig]

Thanks @eitsupi , agree we need to revisit this.

Just wrapping my head around the various levels at which we define 'support'. I agree that it makes sense to transition to less-aggressive rebuild. Also agree it makes sense to split out the cuda stack separately. While I think there probably is some value to being able to preserve older cuda versions in theory, we aren't attempting to track cuda releases anyway, so I'm fine with it building only the last two.

The binder images have been around a lot longer, have a considerable user base and build more directly on the same stack than the cuda images do. I would prefer we do not separate the binder images out from the r-ver stack, at least not without more community input.

I don't quite follow the case for 'deleting' dockerfiles. I'm looking forward to the migration to the new architecture, and I think we don't need to port pre 4.2 images over there if that simplifies things, similar to what we did at the time of the 20.04 LTS release?

[eitsupi]

Thanks, to be clear, I do not want to split the repository, I want to split the build GHA jobs.
In other words, I don't feel the strategy of doing rocker/r-ver and rocker/binder builds at the same time is appropriate.

• In the structure under consideration in Repository structure overhaul #776, if the base image (docker.io/library/ubuntu) has not been changed, the version of the installed packages in images will not be changed due to cache.
  I recently updated the Python package version by forcefully rebuilding all images at the request of upstream (to address a vulnerability in the Python package), but that will no longer be possible.
• The versions of Python packages are not fixed here. Currently, it is common to use dependabot or similar tools to fix and update versions semi-automatically.

In other words, I think it would be better to use the following Dockerfile and requrements.txt and have it updated by dependabot.

FROM rocker/geospatial:4.3.3@sha256:568082b1a92dd9471a522fdf8038c6dd9968dac28599f7457c19ff9da7d89cd0
COPY requirements.txt /tmp/requirements.txt
...

[cboettig]

ah, thanks for clarifying, yes I like this proposal!

[eitsupi]

Closed by #782