[ https://issues.apache.org/jira/browse/AVRO-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14254113#comment-14254113 ]
Niels Basjes commented on AVRO-1537: ------------------------------------ On Linux docker does not _require_ sudo. In fact the docker manual says this: https://docs.docker.com/installation/ubuntulinux/#giving-non-root-access {quote} Starting in version 0.5.3, if you (or your Docker installer) create a Unix group called docker and add users to it, then the docker daemon will make the ownership of the Unix socket read/writable by the docker group when the daemon starts. The docker daemon must always run as the root user, but if you run the docker client as a user in the docker group then you don't need to add sudo to all the client commands. {quote} I always set it up like this (i.e. adding my user to the docker group) and this means that the $SUDO_USER is always unset. So to make both situations work I expect we should have something that only overwrites $USER with $SUDO_USER if it was set. > Make it easier to set up a multi-language build environment > ----------------------------------------------------------- > > Key: AVRO-1537 > URL: https://issues.apache.org/jira/browse/AVRO-1537 > Project: Avro > Issue Type: Improvement > Reporter: Martin Kleppmann > Assignee: Tom White > Attachments: AVRO-1537.patch, AVRO-1537.patch, AVRO-1537.patch, > AVRO-1537.patch, AVRO-1537.patch, AVRO-1537.patch, AVRO-1537.patch > > > It's currently quite tedious to set up an environment in which the Avro test > suites for all supported languages can be run, and in which release > candidates can be built. This is especially so when we need to test against > several different versions of a programming language or VM (e.g. > JDK6/JDK7/JDK8, Ruby 1.8.7/1.9.3/2.0/2.1). > Our shared Hudson server isn't an ideal solution, because it only runs tests > on changes that are already committed, and maintenance of the server can't > easily be shared across the community. > I think a Docker image might be a good solution, since it could be set up by > one person, shared with all Avro developers, and maintained by the community > on an ongoing basis. But other VM solutions (Vagrant, for example?) might > work just as well. Suggestions welcome. > Related resources: > * Using AWS (setting up an EC2 instance for Avro build and release): > https://cwiki.apache.org/confluence/display/AVRO/How+To+Release#HowToRelease-UsingAWSforAvroBuildandRelease > * Testing multiple versions of Ruby in CI: AVRO-1515 -- This message was sent by Atlassian JIRA (v6.3.4#6332)