search

furrer-lab / r-containers

GNU General Public License v3.0
1 stars 0 forks source link

rule to build a new container #12

Closed matteodelucchi closed 3 months ago

matteodelucchi commented 5 months ago

Based on Description file, check if a docker image already exists with the required information. Conditionally build a new one. This is an extension of issue #11 where the description file is being parsed to get the package name.

matteodelucchi commented 4 months ago

Just checking in if there is any progress on this. I added a new package (microbenchmark) to the DESCRIPTION file, causing issues since it has not been installed in the docker file.

Sidenote: This issue relates also to #6.

j-i-l commented 4 months ago

Just checking in if there is any progress on this. I added a new package (microbenchmark) to the DESCRIPTION file, causing issues since it has not been installed in the docker file.

Sidenote: This issue relates also to #6.

addressing it now.

@matteodelucchi for the time being should be create new containers? simply rerunning the pipeline should be enough now.

One thing that might be tricky: Currently we check dependencies on the default branch of the package. New dependencies typically arise first on a development branch which is also where the new containers would be needed.

The container package should almost fetch all branches, read out all versions of the DESCRIPTION file and assemble a set of dependencies.

Alternatively, we just adapt the testing pipelines of the actual software package, so that it starts the container, tries to install any extra dependencies and the runs the test.

The latter option seems the cleanest to me. It will only lead to some issues if newly added dependencies cannot be installed directly in R.

j-i-l commented 4 months ago

This will depend on the decision of furrer-lab/devel-abn#113

matteodelucchi commented 4 months ago

simply update the r-container documentation and close this.

j-i-l commented 3 months ago

Actually, we could choose a middle ground and rebuild the containers once per month, automatically incrementing the version.

For this we might switch to the semver compliant calver versioning and change the logic from on-push-tag to on-push-workflowdispatch which will allow us to start the pipeline manually. We can then add an on-schedule-cron running once a month.

Then we can always automatically increment the claver version, thus leading to monthly updated containers and more frequent ones whenever we push to master.