On Wed, Jul 06, 2011 at 01:47:24PM +0200, Jon Nordby wrote: > On 07/06/2011 12:14 PM, Ramez Hanna wrote: > >On Fri, 2011-07-01 at 10:51 -0700, ext Shane Bryan wrote: > >>As suggested by Auke, I'd rather see the issues addressed w/in the scope > >>of the existing tools. > >I would tend to agree with that, but at least one item hits as not a > >good candidate for solving on OBS side > >speeding up the builds, OBS build functionality always starts from > >scratch, meaning it would cleanup the buildroot and do a clean build. > >then it also depends on having the source in tarball then it would > >unpack it > >I am suggesting to speedup the build process by skipping the > >packing/unpacking, and build inplace without cleaning the buildroot (run > >make and make install but not make clean) thus not rebuilding what make > >script thinks is unchanged > >these tweaks would not be a good thing to implement in OBS because in > >production you don't want that, you'd sacrifice the speed for a clean > >and reliable build > > > I don't see a reason why one could not add a "no-clean-buildroot" > option to the builder in OBS to solve this. Having this option does > not mean it has to be used when OBS is used as a buildbot for > production.
Or, enhance OBS (osc and build actually) to do this with local builds, which seems to be the obvious and least impactful option as it requires nothing from the production build servers and can take advantage of the osc "diffs" (or rdiff) and any already existing local build env and other package files. If local builds are not possible (unsupported host OS for the osc, build, and other tools required) then we need to decide if doing this on the servers is appropriate. I still think it's not hard (changes are encapsulated as patches already), all we need to solve is build root policies for (in no particular order): 1) lifetime - how long to keep around last build root 2) capacity - how much space can be affored to keep build roots 3) identification - how to associate any given "osc ci" request with the appropriate saved build root 4) scope - what projects/packages does this *really* make sense for 5) throttling - ensuring that certain builds don't impact other builds Answering #4 may implicitly solve #3 if we limit build roots to only user home projects. If the answers to #1 and #2 can be determined, and they will allow for exploration of this, I would propose that *all* home projects behave in this way by default, to aleviate the impact all the experimental or development test [re]builds have on production builds. If we enhanced OBS to throttle home projects (think "nice -n -20"), then we improve matters overall, and ensure that any increase in remote (on OBS servers) builds will not impact production builds. In fact, this might be worth exploring (if it's not already done) on it's own just to alleviate any drain on production builds becuase of home and branch builds... just a thought. I would also suggest we need/want a new command/option for osc that lets a developer disable this "re-use the build root" option, or a flag we can set in the packages meta data or from the web interface. As for projects that are Branched from a "production" project... I think we may *want* to force complete rebuilds, if for no other reason than to ensure that they are, in fact, building against what *really* is in the source project the package was branched from. One aspect I'm not sure of is the "use for build" and "publish" flags. I can imagine that "re-using" a build root could (would?) render the result as, at a minimum, suspect for being used to build other packages in the users home, or fail at run time if allowed to be installed by publishing the resulting packages. I can see this really only being valuable for remote, rapid, build and packaging tests when developers are working from unsupported local host distributions or thier supported distro dev system is out of date (and not reasonable to be updated) with respect to the osc/obs tools currently in production. Anyway, just some more random (and rambling) thoughts on the subject. Regards, -- Shane... _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
