<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><br>
    <p>So, I have managed to resolve my problems, so I'd like to report
      back my findings, for the record.</p>
    <p>The main issue was my own confusion about how DockerLatentWorker
      actually operate. Having successfully built my project with
      `bbtravis run`, I expected the basic mechanism to be the same,
      i.e. a Worker "shell" to push commands into a docker instance.
      What I had failed to realize was that a buildbot worker instance
      actually had to run *inside* the container.</p></div></blockquote><div>Yes, this is unfortunate. Easier approach would be to inject the worker binary inside the container, but this is not something we started working on.</div><div> This would allow to use arbitrary docker image for running your builds.</div><div><br></div><div>Normally this is well explained in <a href="http://docs.buildbot.net/latest/manual/configuration/workers-docker.html">http://docs.buildbot.net/latest/manual/configuration/workers-docker.html</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <p>After that clarification, and having rebuilt my docker image
      correspondingly, things started to fall into place (I could
      inspect the logs from the container to see the debug).</p>
    <p>The next stumbling block was the setting up of the communication
      between master and worker. With some help from IRC I was able to
      rewrite the `buildbot.tac` worker code to fetch master name,
      password, as well as some other variables from the environment,
      which the DockerLatentWorker conveniently prepared.</p></div></blockquote><div>That buildbot.tac is already prepared in the official docker images</div><div><a href="https://github.com/buildbot/buildbot/blob/master/worker/docker/buildbot.tac">https://github.com/buildbot/buildbot/blob/master/worker/docker/buildbot.tac</a><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <p>The last item was / is how to establish the master host address
      such that the worker can reach it from inside the container. Given
      that the master passes the hostname down to the worker, and given
      that in my case I was running the worker on the same machine, I
      simply added `--network host` to the worker's `host_config`
      constructor argument, and things started to work. Still, this
      seems a bit hackish at best. Any idea how to do that properly ?</p></div></blockquote><div>You just have to set the <span style="color:rgb(3,47,98);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:12px;white-space:pre">BUILDMASTER </span>variable to the master fqdn. Even if the container runs on localhost, worker  would be able to more easily reach it. as normally, docker takes care of the routing and the dns.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <p>I still think one or two example setups would be nice, as a
      starting point. So far all I have found were exampes using a
      LocalWorker, or (in case of the buildbot metabot), a
      KubeLatentWorker, which is one step too much.<br></p></div></blockquote><div><br></div><div>Feel free to contribute one! :)</div><div><br></div><div><br></div><div>Pierre </div></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p dir="ltr"><br></p>
</div></div>