docker-nextcloud icon indicating copy to clipboard operation
docker-nextcloud copied to clipboard
verified publisher icon hoellen

Weekly builds

Open waja opened this issue 4 years ago • 3 comments

Hi @hoellen,

what's the intention to build the images weekly (https://github.com/hoellen/docker-nextcloud/blob/master/.github/workflows/build.yml#L9) but also update the normal tags (like the upstream major and minor version)? Some people (like me) are running update frameworks like watchtower. (Re)building the images each Friday is not a bad idea at all, but I would not expect to get an image update on regular basis when following (minor/major) version tag, but when a new upstream release happens or new functions/fixes lands in the image.

Do you think that people would instead prefer a tag like "weekly/nightly" and follow this tag when they would like to follow such an image?

Regards, Jan.

waja avatar Dec 10 '21 17:12 waja

The weekly rebuilds are IMO important. With the rebuild, updated packages from Alpine are delivered. Old packages could contain vulnerabilities in packages like PHP, nginx, imagick etc. Rebuilding only for upstream minor/major updates would be not sufficient.

Is there any particular reason why this bothers you? The downtime with the new image is really short, because file permissions are no longer checked on startup. The risk of breaking changes is also very low.

hoellen avatar Dec 11 '21 13:12 hoellen

Hi @hoellen,

yes, security fixes are important. Normally for PHP, nginx and Alpine those are released with a new version, when major security issues arise. So I would expect that if such a major security issue is released, this results into a new minor version release. Do you agree to this?

If you agree, there might be a smarter solution. You can declare the base images with the latest version (and not use the build args for this):

Now comes the smart part. You can use Dependabot for keeping track of new versions. It will generate PRs which you can just merge and with your CI pipeline you have actual images afterwards. I've implemented this in several images (dependabot.yml, PR) and I'll be glad to provide you a PR on this.

Back to what 'bothers me'. My main motivation is, that with deploying new images as soon as they arrive in the registry, this might also happen at normal work hours. Since the PHP session store is located at /php/session, this results into an empty session store after image update and every user is logged off. This happened last friday. :) I worked around this issue and added a persistent volume to /php/session.

It feels a bit strange about to update an image without knowing it had no impact (beside logging out users :).

Okay ... how would a solution looks like if I could wish something from st. clause? :)

  • Switching to the dependabot solution (just tell me an I send a PR)
  • Don't build the latest and the version tags nightly/weekly... How about setting up such a tag and build this also when building latest and the latest version tag (which should actually the same)? This should result into what you actually doing, when following this tag.
  • maybe adding a volume to /php/session to save session files persistent?

Just my two cents.

waja avatar Dec 11 '21 15:12 waja

With monitoring only alpine, php and nginx you forget all the other packages which will be upgraded in a weekly build which could get security fixes (e.g. Linux kernel, libraries, etc.) So I'm in favor in keeping the weekly build. As you mentioned yourself, I would just persist /php/session directory.

hoellen avatar Jan 13 '22 19:01 hoellen