Update bioconductor_docker images for consistency w/ upstream Rocker images

[nathanweeks]

After the upstream Rocker project builds container images for a new R release version, container images for the previous version are rebuilt to pin specific CRAN and CTAN repository dates, and the RStudio Server version is updated until that occurs:

https://github.com/rocker-org/rocker-versioned2/wiki/Versions

e.g.,

$ docker run -it --rm rocker/ml-verse:4.3.1 rstudio-server version
...
2023.09.1+494 (Desert Sunflower) for Ubuntu Jammy
$ docker run -it --rm rocker/ml-verse:4.3.1 env | grep -e CRAN -e CTAN_REPO
CRAN=https://packagemanager.posit.co/cran/__linux__/jammy/2023-10-30
CTAN_REPO=https://www.texlive.info/tlnet-archive/2023/10/30/tlnet

However, the bioconductor_docker image build schedule is such that corresponding bioconductor_docker images are not necessarily consistent w.r.t. their RStudio Server, CRAN, and CTAN versions:

$ docker run -it --rm bioconductor/ml-verse:3.17-R-4.3.1 rstudio-server version
...
2023.06.2+561 (Mountain Hydrangea) for Ubuntu Jammy
$ docker run -it --rm bioconductor/ml-verse:3.17-R-4.3.1 env | grep -e CRAN -e CTAN_REPO
CRAN=https://packagemanager.posit.co/cran/__linux__/jammy/latest
CTAN_REPO=https://mirror.ctan.org/systems/texlive/tlnet

Would it be possible to adjust the bioconductor_docker container image update cadence so it behaves similarly w.r.t. RStudio Server version & CRAN/CTAN repository version locking? (E.g., after a rocker image is released for a new R version, rebuild the corresponding bioconductor_docker images for the previous version)

[almahmoud]

I think overall the answer is yes, that is something we should likely do, and thank you for pointing it out!

In case helpful, jsyk BiocManager has internal logic that tries to use the Bioconductor binary repository when in the Bioconductor container, so you might notice packages downloading from bioconductor.org/../container-binaries/... instead, which we pin per Bioconductor version. You can turn this off by setting the env variable BIOCONDUCTOR_USE_CONTAINER_REPOSITORY=FALSE.

In any case, especially given that we don't version the repository per date or R patch version, I agree that we should be updating the old containers to the pinned rocker containers when they become available.
We currently keep old versions passively, so we never rebuild old ones. I might try to implement this as part of a separate auto-update workflow that detects rocker updates and can also bump the current workflows. I'll rebuild 3.17 manually for now too and update it to 4.3.2 as well.