[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: include doc and RPM build process in origin-server file tree?

I'm not familiar enough with the devenv/build particulars to speak to the implementation details to accomplish this, but I think it's a great idea to extract the build into a discrete uniform task and decouple it from devenv however possible. Being able to run a simple command to construct a fresh local repo ready to be consumed by a VM, a devenv, etc. would be a great conceptual and mechanical simplification.

I'm a bit unclear on how cross-tree dependencies would work, but Clayton has already alluded to some way of accomplishing it. I'll be interested to watch the exploration of that challenge...

On 03/11/2013 01:04 PM, Mark Lamourine wrote:
Recently I've been writing up what it takes for someone who wants to build the origin-server packages on their own.  The nuts and bolts of finding the root of each RPM directory and (one way of) identifying the list of build dependencies is posted at http://cloud-mechanic.blogspot.com/2013/03/the-bleeding-edge-building-openshift.html

devenv will do all three of these tasks (install dependencies, build RPMs, generate docs) but it seems strange to me that I *need* a additional tool (meant to generate AMIs for testing) just to build the RPMs and yum repo. I think that we may already have tools in place that with a little work would automate these tasks without requiring an additional non-standard tool. In fact, Krishna's already done some of this in the Rakefile at the top of the tree.  There's a target there named doc:gen that will walk the entire source tree and generate yardoc documentation, placing it in a location at the top of the tree.

My first inclination is that comparable targets for gems (where applicable) and rpms would make the build process more intuitive for people who want or need to build the packages but do not need all of the additional aspects of building AMIs or liveCD images.

I've put together a quartet of rake tasks that, if placed in the root of the right directories could be used to get the effect I'm looking for.  It would not be hard to write a task at the root that would call these for all package trees.


require 'yard'
desc "Generate documentation"
YARD::Rake::YardocTask.new() do |t|
   docdir = ENV['docdir']
   if not docdir == nil
     t.options = ["--output-dir", docdir]

# Install build requirements
# Use sudo(1) if caller is not root
desc "Install build dependencies for this package"
task :builddep, :answer do |t, args|
   specfiles = Dir.glob("*.spec")
   if specfiles.length != 1 then
     raise Exception.new("there must be exactly one specfile")
   builddep_cmd = "yum-builddep #{specfiles[0]}"
   if not args['answer'] == nil then
     if not ['yes', 'no'].include? args['answer']
       raise Exception.new("builddep answer must be 'yes' or 'no'")
     builddep_cmd += " --assume#{args['answer']}"
   builddep_cmd = "sudo " + builddep_cmd if not Process.uid == 0
   system builddep_cmd

desc "Create installable RPM package"
task :rpm, :test do |t, args|
   build_cmd = "tito build --rpm"

   repodir = ENV['repodir']
   if repodir then
     if not repodir == nil && (not File.exists? repodir) then
       raise Exception.new("RPM directory does not exist")
     build_cmd += "--output #{repodir}"

   if args[:test] then
     build_cmd += " --test"
   system build_cmd

desc "Create installable RPM package for testing"
task :testrpm do


A set of tasks in the top Rakefile which would find and invoke those further down in the tree would make rebuilding single components or the whole tree a fairly simple matter, both self-contained and consistant:

rake yard - generate docs here (and below)
rake rpm  - generate the most recent tagged package
rake testrpm - generate a test package or packages


* use existing well known tools
* remove complexity from devenv (let it do what it does well)
* consistent task method (you want to X, use rake)
* ability to work at the appropriate scale (build one, build all)
* task code is kept close to the source code (allows customization as needed: pam_openshift?)


* global changes to build tasks require changes in each RPM root.
* "duplicates" functions already in devenv
* install build dependencies requires one call per RPM (likely duplication)

Comments? Other suggestions?

- Mark

Dan Mace
Senior Software Engineer, Red Hat

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]