I'd like us to start offering 389ds images on docker hub - and ideally, I'd like
to automate this process as much as possible.
As I've historically been the person who has been pushing this the most, I'm happy
to maintain and coordinate that these are updated and released when the project updates
Due to the way docker works, we only need to make sure that what we have in the volume
/data is readable and operational, so I think there is no issue with what base image we
choose for the container image, because we can always change it later without affecting
the user as /data is always the way we'll access and present the container state.
For me, I'd probably setup an automated build from git master on a :devel tag or
similar in docker hub, and :latest would be the latest major series release (1.4),
probably shortened to :4, with the point releases in there too, IE :4.1, :4.2. patch
releases would just be updates to those streams. If possible I'd like to automate
those from our git branches. The best way would probably be to make a git mirror to
github/gitlab which can then have triggers to call docker hub to do necessary updates.
A major question is how we actually do the build - do we build from the source tree, or do
we build from a rolling repo like the network:ldap repo in opensuse (which is always
following upstream releases). I think building from source is the most flexible, as it
gives us the closest relationship to git and our upstream release process.
Senior Software Engineer, 389 Directory Server
Show replies by date