Re: Rationale for having master builds in docker containers?

On Thu, Dec 06, 2018 at 11:28:53AM +0100, Harald Welte wrote: Those are the projects that run the python-based external tests, which involve opening up VTY and CTRL ports among others, because we start up the program and interact with it on VTY and CTRL. That means each of those projects is not able to run tests more than once per slave, or we get sporadic conflicts of not being able to start the main program. That was really annoying. Another complex way would be to round robin through a range of ports or localhost addresses or something, and tweak the .cfg for each test run so that the ports never conflict :/ Or some sort of network segmenting? ah yes. I think the only really good reason to build the manuals in a jenkins build that also runs 'make check' is that we want to catch asciidoc bugs in the patches submitted for the manuals. But to publish, it could make more sense to have a separate job for the manuals, i.e. build and publish the manuals from a jenkins job that does not use docker to de-collide the ports. That also doesn't need several build axes, just the one build config that enables the most software components. Why? well, that is the other complication, because we (want to) auto-generate VTY reference data from the main program. That then would also require starting the program and firing up VTY ports and avoiding conflicts. But I'm also having an idea here, that we introduce a cmdline option that directly dumps the VTY reference to stdout instead of having to connect via VTY and without opening any ports. Another idea would be to somehow run contrib/jenkins.sh in the docker, but in the jenkins job extract the generated manuals from that docker to publish them. ~N