nodejs / build-containers Goto Github PK

README.md states:

For reference, the Jenkins build server for io.js runs the following command:

docker run -a stdin -a stdout -a stdin -t --rm -v ${PWD}:/opt/node/ node-forward-ci:node-${DISTRO}

-a stdin -a stdout -a stdin

Is this supposed to be -a stdin -a stdout -a stderr?

There's a known bug with child process reaping in Docker containers.
Here's an article that explains in some details what this issue is about:

http://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/

My question is if it would be worth to integrate a small init script in C or Python to fix this bug on the Docker images of this repo. ?

UPDATE: Here's the author's example init script in python used for his Docker base-image project:

https://github.com/phusion/baseimage-docker/blob/rel-0.9.16/image/bin/my_init

According to the docker best practices guide, you should "avoid RUN apt-get upgrade or dist-upgrade, since many of the 'essential' packages from the base images will fail to upgrade inside an unprivileged container".

Furthermore, Michael Crosby states that "Because of the isolation that happens [apt-get upgrade] can often fail if something is trying to modify init or make device changes inside a container".

Why do all of the containers run apt-get upgrade if it is discouraged by the docker community?

We are putting together a governance model for the io.js build team, which this repo will be a part of. To be part of this conversation, check out: nodejs/build#49

Do a cp -a (or similar) within the container to make a local copy of the source tree under the iojs uid to solve potential problems with conflicts and permissions. Also exclude .git (and perhaps anything in .gitignore?) during the copy to speed it up a little.

Assigned to @ghostbar

https://registry.hub.docker.com/u/iojs/build/

Should be able to docker run iojs:iojs-ubuntu-trusty and docker run iojs:libuv-ubuntu-trusty to pull the builds from Docker Hub.

Debian builds are not working, an adduser thing: https://registry.hub.docker.com/u/iojs/build/builds_history/95020/ / @ghostbar

Happy to discuss naming or anything else in this thread. We also should probably update the README with more details, #6 needs a bit of work based on the feedback I gave there and we should mention Hub.

Once this is working nicely we'll switch the build machines to pull from there and not have to run their own builds.

Available in the repo under adduser. Worth installing an extra package for this? Going to include it in the coming pull request, but perhaps a better approach would be using default debian tools.

I've just noticed this, having installed Docker 1.3.2 and running the containers locally, I get EACCES type failures with about 5 of the tests. They all seem to be about child processes and pipes and are related to Docker's new security model. If you run with --privileged then it's fine but that's not desirable for us. It's not a capabilities-related thing because --cap-add=all doesn't make a difference.

For test/simple/test-cluster-http-pipe.js at least (the one I've been mainly focusing on), I've narrowed it down to a read() on the pipe file descriptor on the child in libuv, the connect() is fine, it's only when you start reading that you get the EACCES. My instinct here is to blame Docker, but it's possible that libuv, or even Node, are doing something wrong. The error is as if we're trying to read from protected /dev/ nodes but I'm pretty sure we're note going anywhere near them. No matter where the pipe is put (can be changed with the NODE_COMMON_PIPE env var) it still happens, I've tried /opt/iojs/test.pipe, /tmp/test.pipe, /home/iojs/test.pipe and others to no avail.

If anyone else has a clue or time to chase this down it's be greatly appreciated because this is a big blocker now to getting tests happening on pull requests. I don't even know where to escalate this bug to at the moment or even if it's just isolated to my machine!

Debian infrastructure is certainly slower than Ubuntu and while libc6 on Ubuntu is already 2.19 on the current debian stable is 2.13 (and yet a lot of people insist on using Debian stable for their servers).

This will change soon on the libc6 side after the current testing (aka jessie) is released as stable but I think it will happen again that debian will have older versions in it's stable version than ubuntu.