[ 
https://issues.apache.org/jira/browse/AVRO-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tom White updated AVRO-1537:
----------------------------
    Attachment: AVRO-1537.patch

Here's a new patch that sets USER to SUDO_USER if set, otherwise falls back to 
the current user, as suggested by Niels.

To answer Niels points:
* It would be great to use Docker to run on Jenkins, but I'm not sure we can do 
that at the ASF yet. We can address any issues that arise to do with naming 
when they arise.
* The Dockerfile does not specify which versions of each library to use, so you 
are right that when they are updated we might get failures due to 
incompatibilities. I propose we address them on a case-by-case basis - since 
they may uncover bugs that need fixing in the Avro code or tests.
* Regarding the question about testing different versions of Java, Ruby etc - 
we could add more Dockerfiles for the different combinations. Separate issues 
would be best for that.



> 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, 
> 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)

Reply via email to