Mailinglist Archive: opensuse-buildservice (206 mails)

< Previous Next >
Re: [opensuse-buildservice] Thoughts on OBS as a git bisect build cluster
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Mon, 2 Mar 2009 10:24:38 +0100
  • Message-id: <200903021024.38850.adrian@xxxxxxx>

Hello Brandon,

Am Samstag, 28. Februar 2009 02:56:20 schrieb Brandon Philips:
Hello-

I want to create a web based tool where users could do git bisections
themselves by plugging in starting hashes (provided by a developer most
likely) and get an RPM out. Then as they test they come back to the
website to report their test results, good or bad, to get the next rpm
to test.

Now, the most intensive part would be doing all of the builds and
checkouts. Something that I think OBS could handle nicely :D

First, is this use of OBS is acceptable?

I see two sides on this:

1. It is good to have such a support. The idea is good and it can indeed help
in various cases. If not for build.opensuse.org it is at least very good to
have for other instances.

2. OBS at build.opensuse.org is already very high loaded most of the time, it
still has it's free cycles.
So I would propose that we invent a system to mark such builds somehow as
low priority by default.

This support might use the temprary build support, fate #305931, instead of
creating porjects/packages btw.

If so the next challenge is avoiding lengthy and expensive uploads to
the OBS. I have thought up a few strategies for doing such and would
appreciate feedback:

1. Create an OBS project with a base version of the project tarball e.g.
Kernel v2.6.28, then generate a patch with:
$ git diff v2.6.28...<$BISECTHASH>
Then branch this OBS project to create a project that will build the RPM
for the user with this git diff patch applied.

I would like to see also support to rebuild a submitted source changes, based
on the history of our source server.

2. Create an OBS project with a tar snapshot of the external git repo
and submit it to an OBS project. Then create an OBS branch from this
project for each git bisection step and submit some control file that
tells the spec file what hash to build.

3. Have a spec file that does a clone from some internal mirror of the
external git tree and does the bisect locally. (Can you get to the
internet when building inside a VM?)

No, by intention.

For #1 and #2 I would need a way to submit a patch to a branched project
_without_ doing a full checkout of the tarball again. How would I change
one file in an OBS branch without downloading the whole repo?

What do people think? Any other strategies to create something like this
that uses OBS on the backend?

From my point of view, we have way more often the case that we need to findout
regressions about submitted packages. Just because this is what our users are
testing.

So from my personal perspective it is more important to rebuild all submitted
sources than working on external cvs/svn/git repos.

bye
adrian

--

Adrian Schroeter
SUSE Linux Products GmbH
email: adrian@xxxxxxx


--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups