On 2019-03-13 9:48 a.m., Pierre Tardy wrote:
So, I have managed to resolve my problems, so I'd like to report
back my findings, for the record.
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.
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.
This would allow to use arbitrary docker image for running your builds.
Normally this is well explained in
http://docs.buildbot.net/latest/manual/configuration/workers-docker.html
Well, yeah, in hindsight it looks clear. The problem is that before you
understand it, it has to be clear, too. :-) (But slightly more
seriously, I agree it's actually clear: I was blinded by my own wrong
expectations.)
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).
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.
That buildbot.tac is already prepared in the official docker images
https://github.com/buildbot/buildbot/blob/master/worker/docker/buildbot.tac
Fair enough. This is also a bit confusing: there are many different ways
to use docker: one is to simply encapsulate the environment to run
buildbot *in* (once for the master, once for the worker), another one is
to use *inside* the worker. Combined with my confusion as to whether
docker runs inside the worker, or the worker runs inside docker
(actually both !), this didn't help.
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 ?
You just have to set the BUILDMASTER 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.
well, without the `--network host` argument I wasn't able to reach the
master under its fqdn.
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.
Feel free to contribute one! :)
I'm considering it (once my comfort level improves a bit). I'm also
considering to contribute to the buildbot_travis extension: I'm now
using a slightly different yml spec, so generalized the code that maps
the yml file to a set of builds with corresponding build steps.
The travis-ci spec would then be a particular instance of that...
Thanks,
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________
users mailing list
users@buildbot.net
https://lists.buildbot.net/mailman/listinfo/users
