Would there be ways to automate a rm -rf of a build workspace when the
build has completed? Doing so would make the problem disappear. Surely
builds take a little more time and disk, network and cpu usage will grow.
But builds start from a pristine workspace which is desirable from my pov
and the full disk problem disappears too so long a single job does not use
more than the available on a build machine.
On Fri, 20 Jul 2018, 19:52 Dan Kirkwood, <dang...@apache.org> wrote:
> Thanks, Mike..
>
> I've added some better cleanup, I hope, using trap -- so hopefully will
> lessen our contribution to the problem.
>
> -dan
>
> On 2018/07/20 16:43:31, Mike Jumper <mjum...@apache.org> wrote:
> > On Thu, Jul 19, 2018, 10:36 Dan Kirkwood <dang...@apache.org> wrote:
> >
> > > TrafficControl uses docker-compose to build each component, so the
> disk
> > > space used is within docker's space -- not the workspace. We do
> attempt
> > > to clean up after each build, but would be happy to get advice to
> improve
> > > how we're doing it. Are there best practices others use?
> > >
> >
> > We've been using Docker for Guacamole's Jenkins builds, as well,
> > autogenerating a Dockerfile which performs the actual build within a
> > pristine environment.
> >
> > Not sure how different things would need to be with docker-compose, but
> we
> > use a combination of the "trap" command (to ensure cleanup happens
> > regardless of build result) and the "--no-cache" and "--rm" flags:
> >
> > # Remove image regardless of build result
> > export TAG="guac-${BUILD_TAG}"
> > trap "docker rmi --force $TAG || true" EXIT
> >
> > # Perform build
> > docker build --no-cache=true --rm --tag "$TAG" .
> >
> > - Mike
> >
>
