Setting up a clean local build environment [SOLVED]

[roarde]

I need an extremely lightweight setup for this. I'll only be able to build 32-bit, so allowing for additonal arches isn't an issue -- that'll have to be tested elsewhere. Of course, I'll still need to use network and have access to our SlackBuild repositories. Just for 7.1 (installed) for now; others can come later.

Suggestions?

[M0E-lnx]

Not exactly "extremely light-weight", but the easiest way to do this would be with docker.

Docker runs on 7.1 out of the box.

Our docker documentation explains how to get it setup and running.  Here is that doc  http://vlcoredocumentation.readthedocs.org/en/latest/manuals/docker.html

After your docker daemon is up and running, You will need to download this image
http://vlcore.vectorlinux.com/pkg/vlbuildslave/docker-images/VL-7.1-BB-FINAL_vlbb-docker.tar.xz

then import it into docker

Code: [Select]

cat VL-7.1-BB-FINAL_vlbb-docker.tar.xz | docker import - vector:7.1-bbafter that, you can enter the clean build environment as many times as you want

To get a new clean environment:

Code: [Select]

docker run -ti vector:7.1-bb /bin/bash
if you want to save any of the data from inside that container to the host OS, mount a volume in your docker run command

Code: [Select]

docker run -ti -v /home/your-docker-work:/data vector:7.1-bb /bin/bashThis will create a bind mount between the host and the docker container.  All the data you place in /data will be saved back to the host, that way when you exit the container, the data you want to keep is kept.

see "docker help run" for more, especially, you may want to consider adding the "--rm" argument to docker run for automatic clean up.

THINGS TO REMEMEMBER:
* Everything is disposable in docker, so the data you want to keep you have to bind mount from and to the host (as above)
* You only need to deploy the image once, after that you can create as many containers as you want.

Like I said,
Not exactly "extremely light-weight", but it is as light-weight as it gets in 7.1
HTH

[roarde]

It's taken me nearly a month to find bits and snatches of time to process this. I should have responded sooner.

It's almost as lightweight as the ideal I had in mind, and it's worth the few extra bytes. Thanks for setting this up, writing the docs, and letting us know about it, M0E-lnx!

Only remaining objection I had was the typing involved each time a container was (re)started. But that's not hard to handle, right? With the clone of my vl71 fork residing at ~/gits/vl71-roarde and a directory of disposable items kept at ~/scratch, I tag this function to the end of ~/.bashrc:

Code: [Select]

s71(){ # List, create, re-enter, or remove vl71 docker containers

  case $# in
    0) # With no parameters, list containers
      docker ps -af 'image=vector:7.1-bb'| (
        while read; do
          set -- ${REPLY}
          [ "x$1" = "xCONTAINER" ] || { shift $(( $# -1 )); echo $1; }
        done
      )
    ;;
    1) # Start existing container $1, or create new
      docker start -ai $1 || {
        echo Creating new container \""$1"\"
        docker run  -ti -v ~/gits/vl71-roarde/var/vabs:/vabs \
          -v ~/scratch:/scratch --name "$1" vector:7.1-bb /bin/bash
      }
    ;;
    2) # Remove container or list its details
      case "$1" in
        "ls") docker ps -af 'image=vector:7.1-bb' -f "name=$2" ;;
        "rm") docker rm "$2" ;;
           *) echo \""$1 $2"\"'. Really?'; return 1 ;;
      esac
    ;;
    # This disallows multiple params for ls, rm; maybe for the better
    *) echo 'oops!'; return 1 ;;
  esac
}Rather than import tools (like my text editor) into the container, I choose to do the work other than the build from a terminal running directly on my host. As mounted, the changes are accessible from inside, as you said.

Adding 64-bit containers would be trivial should I find myself on such a machine. Just rename "s71" to "s7132" and modify that to get an additional "s7164". Grab and process
http://vlcore.vectorlinux.com/pkg/vlbuildslave/docker-images/VL64-7.1-BB-FINAL_vlbb-docker.tar.xz
just as above. Probably would want to add arch tagging of container name to my functions, but I'll worry about that  should I get there.

What I like most is that separate containers can be used for each potential package, and the overhead is just the difference between the new container and the original image -- rather than a whole new, duplicated filesystem for each project like would be needed to do that with chroot alone or such.

[M0E-lnx]

Glad it was helpful

[roarde]

It's been working well for a while now, but I'd forgotten to mark this solved. There ya go.