search

rocker-org / rocker-versioned2

Run current & prior versions of R using docker. rocker/r-ver, rocker/rstudio, rocker/shiny, rocker/tidyverse, and so on.
https://rocker-project.org
GNU General Public License v2.0
390 stars 163 forks source link

BREAKING: repository structure change #782

Closed eitsupi closed 2 months ago

eitsupi commented 2 months ago

Part of #776

eitsupi commented 2 months ago

@cboettig Sorry for the delay, but now that we can generate at least some Dockerfiles and bakefiles, could you please take a look at this?

eitsupi commented 2 months ago

But in this new setup is it still possible to occasionally build older versions in order to benefit from the ubuntu-lts security patches released for them?

This is only possible for images that have the exact same structure as the most recent images.

For example, r-ver is fine for all versions, but rstudio cannot go back beyond a certain point because it becomes impossible to build linux/arm64 platform at some point.

eitsupi commented 2 months ago

@cboettig Do you think geospatial-ubuntugis is still needed? I would like to remove this as I don't think any work has been done on these images in the last few years.

eitsupi commented 2 months ago

Sorry but my work was too slow to complete the work before the R4.4.0 release. (There is probably little problem with the image build, but the report generation should not work due to the removal of the stack file. That needs to be fixed.)

I would like to do a build with the current structure for the R4.4.0 release and then polish and merge this PR in about a week or so.

cboettig commented 2 months ago

Do you think geospatial-ubuntugis is still needed?

nope, let's drop this one!

eitsupi commented 2 months ago

Since ml and ml-verse keep failing to build (and of course failed today), the latest version still seems to be stuck at R 4.3.2.

image image

I think we need to finish and merge this PR soon and change it to do multi-stage builds and streamline it.......

cboettig commented 2 months ago

Since ml and ml-verse keep failing to build (and of course failed today), the latest version still seems to be stuck at R 4.3.2.

Looks like these are all due to inadequate space on the Github runner, right? (e.g. https://github.com/rocker-org/rocker-versioned2/actions/runs/8816018461/job/24199213471#step:7:4638 , no space left on device). Like you say, hopefully we can avoid that with the new build strategy.

eitsupi commented 2 months ago

Looks like these are all due to inadequate space on the Github runner, right?

Yes, as you noted somewhere perhaps this is related to the number of parallels, but I don't know what the limitation is. It is the cuda images that always fail, so perhaps when we parallelize, the spare storage is also split?

In any case, the number of parallelism is reduced in this PR to begin with, and even if the build fails, there will be no problem using the cache to repeat the build again (nothing will be changed except the failed image).

nathanweeks commented 2 months ago

Since ml and ml-verse keep failing to build (and of course failed today), the latest version still seems to be stuck at R 4.3.2.

Looks like these are all due to inadequate space on the Github runner, right? (e.g. https://github.com/rocker-org/rocker-versioned2/actions/runs/8816018461/job/24199213471#step:7:4638 , no space left on device). Like you say, hopefully we can avoid that with the new build strategy.

In case a stop-gap solution might be helpful, the GitHub-hosted runners have a second block storage device with a mostly-unused file system mounted at /mnt:

runner@fv-az1432-846:~$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop0     7:0    0 63.9M  1 loop /snap/core20/2182
loop1     7:1    0   87M  1 loop /snap/lxd/27948
loop2     7:2    0 39.1M  1 loop /snap/snapd/21184
sda       8:0    0   75G  0 disk
└─sda1    8:1    0   75G  0 part /mnt
sdb       8:16   0   75G  0 disk
├─sdb1    8:17   0 74.9G  0 part /
├─sdb14   8:30   0    4M  0 part 
└─sdb15   8:31   0  106M  0 part /boot/efi
runner@fv-az1432-846:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        73G   53G   21G  72% /
tmpfs           7.9G  172K  7.9G   1% /dev/shm
tmpfs           3.2G  1.1M  3.2G   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sdb15      105M  6.1M   99M   6% /boot/efi
/dev/sda1        74G  4.1G   66G   6% /mnt
tmpfs           1.6G   12K  1.6G   1% /run/user/1001

A job step that relocates the the docker root directory to this "spare" file system could be added at the beginning of a job; e.g., containing commands like the following:

sudo sed -i 's#^{#{"data-root":"/mnt/docker",#' /etc/docker/daemon.json 
sudo systemctl restart docker

Disclaimer: I've only tested this approach interactively on a runner, where I verified docker pull worked & used /mnt/docker.

eitsupi commented 2 months ago

@cboettig I will try to merge this in tomorrow if there are no concerns expressed. (However, I would like to cancel the image build and keep watching the devel build for the next few days)

cboettig commented 2 months ago

nice, all this looks good to me. looking forward to this new setup.

cboettig commented 2 months ago

@nathanweeks many thanks for this tip! I can confirm this works on other builds I've tried with very large images, e.g. https://github.com/boettiger-lab/k8s/actions/runs/8857066532/job/24324087762

![Uploading image.png…]()

eitsupi commented 2 months ago

Let's merging for now...