Scheduled builds?

[eitsupi]

I was wondering if we should add a cron trigger to the action to ensure an auto-build of the latest image on a predictable schedule? Maybe once a week? I think it would be nice to ensure that the latest image is a relatively recent build across the board, e.g. that we're not a month behind pulling in patches to security-related libraries that aren't installed in the base image by default, (e.g. network-related libs like openssl / curl). This also serves to keep R packages more up-to-date though that's probably less important.

Originally posted by @cboettig in #668 (comment)

[eitsupi]

We used to build every time we updated the Rocker scripts (scripts dir), but this was changed about a year ago in #504 to build only when updating the Dockerfile, as I felt this made too many builds.

I think that building too many times is undesirable in the following points:

1. Downstream repositories may need to be updated more than necessary due to dependabot, etc.
2. It is likely to be a waste of capacity.

Docker Official Images are updated when upstream images are updated, etc., and may not be updated as often as once a week.

If we set up a build to happen every Monday, then the next Monday after a new version of R is released we will have a new build in just a few days.
So I strongly oppose builds by cron.

I would not disagree if the job, for example, checked the time elapsed since the last build and triggered a build if more than 30 days had elapsed.

I have read the dependabot source and it seems to use the Docker Registry API.
I have been hesitant to use it because it requires authentication, but I believe it can be used to detect base image updates and elapsed time since the last build.

[cboettig]

Balancing resource demand on downstream repos and not being headless of resource use are both good points. I do think having some form of automated trigger mechanism would be reasonable though. A cron task in the action seems to me the simplest and the most transparent option (I don't know how to have the Github action detect base image updates).

[cboettig]

Maybe a monthly tempo would be appropriate?

I'm definitely up for other options, just not sure what they are. I just think when a user looks at the repo builds they should be able to determine when they might expect the next build to happen without needing to open an issue. Of course we can also continue triggering manual builds when necessary to meet needs of downstream repos and users.

[eitsupi]

I don't know how to have the Github action detect base image updates

Since ubuntu have tags with the date it was released (like ubuntu:jammy-20230605), the API can detect the last build by retrieving the tag.
https://docs.docker.com/registry/spec/api/

Maybe a monthly tempo would be appropriate?

I think the frequency of once a month is reasonable. The release frequency of ubuntu, the base image, is also almost once a month.

I just think when a user looks at the repo builds they should be able to determine when they might expect the next build to happen without needing to open an issue.

I strongly agree with that (I would have asked you that too), but I feel that the user's interest is mostly in the new R or RStudio and that the other cases may be quite specific.

[jan-abel-inwt]

Hi there, thank you for your hard work and the excellent R images. Are there any updates on the scheduled builds? Are you planning to do regular builds also for older R versions?

[eitsupi]

I don't think there is anything more than what is written here at this point.

I think I've seen requests for scheduled builds in other issues, but I don't know the best strategy for mixing builds from Dockerfile updates with scheduled builds (i.e., just a few minutes after a scheduled build, a new RStudio release could be made and built again).