Anatoli Fomenko created BIGTOP-720:
--------------------------------------
Summary: Build environment automation
Key: BIGTOP-720
URL: https://issues.apache.org/jira/browse/BIGTOP-720
Project: Bigtop
Issue Type: Task
Components: General
Reporter: Anatoli Fomenko
Assignee: Anatoli Fomenko
Fix For: 0.5.0
Summary of the bigtop-dev discussion:
A few approaches have been suggested:
# (Roman) maintain a parallel (very shallow) collection of puppet code that
would, essentially, manage our "build slaves"
# (Roman) do #1 but automate it in such a way that the info actually gets
harvested from spec/conrol files. (Cos suggested to use Groovy for
implementation)
# (Bruno) VMs.
There are some pros and cons for each of them.
For example:
#3 Pros:
(Bruno) Tools like Boxgrinder and Oz can deal with multiple OSes and can create
local images as well as push them to the cloud. The build would be repeatable
and would not require any effort from the end user (apart maybe providing
Oracle JDK, but that would have to be the case whatever the solution). Future
contributors would just need to boot their VM to get started and hopefully ease
contribution.
(Roman) I'd love if I could say
{code}
$ vagrant add box/up
{code}
and get the environment up and running without much fuzz.
#3 Cons:
(Cos) I think boxed environments (like VMs) are an overkill... old proven
toolchain type of environment that can automatically bootstrap upon a fresh
install (or update itself: think Maven model) and pull whatever apps are
required in whatever form they might exist... Such approach would be more fluid
than a somewhat rigid VMs, that would have to be updated periodically,
versioned, etc. Another benefit of a toolchain is that BigTop packages might
have to redistribute/wrap some of the tools for later use once a package is
installed on a customer's system.
There are some tools based on SRPMs that can extract a dependency list.
Roman suggested a simpler approach of grepping and using sed/awk:
{code}
$ git grep -E 'Build(Requires|-Depends):'
{code}
Sean was ... in favor of the idea of extracting dependencies from the control
and spec files and building a script that will install the necessary tool
chain.
Cos mentioned ... It should work, except for build-time dependencies which
aren't declared in the bigtop packages (e.g. libtool, etc.). So, I'd vote for a
separated list of build-time dependencies being maintained.
Roman separated 3 distinct use cases:
# provisioning/maintaining a long running Jenkins slave
# provisioning a host dev environment
# provisioning a VM dev environment
Roman also suggested ... a 'virtual' package called build so that running:
{code}
$ make build-[rpm|deb]
{code}
will create a package that would download all the bits and pieced of a
tool-chain AND also promote BuildRequires: to its own Requires: so that
installing this package will give you all the toolchain bits and all the
package deps at the same time.
The consensus seems to be that all approaches are valid for some use cases, so
implementation may start from simpler approaches, and evolve as necessary.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
