[
https://issues.apache.org/jira/browse/AVRO-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253656#comment-14253656
]
Niels Basjes commented on AVRO-1537:
------------------------------------
Hi [~tomwhite],
I checked your current patch and I really like it.
I did a test on CentOS 6.5 x86_64 inside a Virtual Box in Windows 7 and this
works really great.
The first build takes a while and then subsequent runs are within a second on
the screen.
The Java build went perfect and I let it run for a while and it all seems to
work fine (until it all stops with the known bug {{./build.sh: line 25:
node_modules/grunt/bin/grunt: No such file or directory}}).
A few feedback points:
# Using the naming like {{avro-build}} and {{avro-build-$USER}} means that
there can only be a single images at a time with that name.
So in the scenario where you want to enhance the image (i.e. edit the
Dockerfile) and then a different user on the same system cannot use the build
system reliably; there will be conflicts between those two users. I realize
this is an extremely unlikely scenario in normal development situations. I'm
sure not how unlikely it becomes when we make this docker part of the normal
build and run it on a shared CI environment (i.e. Jenkins) where everything
runs as the same user.
I think it is fine to do this form as long as we realize (and preferably
document) this caveat. Perhaps something a comment as simple as "The "build.sh
docker" environment is intended for use on personal development systems."
should suffice.
# The Dockerfile does the installation of the various things by means of naming
the tool that needs to be installed. Then this docker image will be different
if for one of the tools a new version is released. So I was wondering;
## What happens if in the future one of those tools creates a regression or a
incompatible change in their API? Like the PHP NaN example? Is that a good
thing because you're actually building and testing against what end users will
be using too? Or is this a bad thing because you have a changing build
environment?
## What happens if in the future one of those tools is updated and it is an
update that is really needed for the build to succeed? How can it be
validated/ensured that the image is updated too on the desktop of the
developers? Perhaps the project can be enhanced to ensure/enforce minimal
versions of the tools that are needed?
# I vote you push back the improvements towards HBase where you based the
original on (at least make a ticket in HBase {{Evaluate Docker improvements
from AVRO project}}).
> 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)
