Re: Adding bibisect repository support to tinbuild2

On Sat, Jul 21, 2012 at 5:12 PM, Norbert Thiebaud <nthiebaud@gmail.com> wrote:
> So... I committed you patch, and then refactored it 'a bit'

Yeah, sorry for making you do a big reorg of all of my code. I'll try
to send smaller patches in the future so they'll require less surgery
from you afterwards.

> First I separated the operation in 3 differents operations:

(reading through that now)

> TODO: right now we make install and deliver at every build... there
> may be a reason to do that less often... but the logic to only
> conditionally do that is not obvious. time based suck,

How much of a time suck are we talking about? The machine I set up to
test the build machinery is pretty old, so the post-build steps
(install, copy, git add/commit/push) take up a non-negligible amount
of time. On a modern fast buildbot, I'd hope those operations would
take no more than... 5min? 10min?

> Note: I presume that the bibisect repo as a branch that match the
> branch we are building on in the source. we switch to that branch
> before each build.

Do you mean the bibisect repo *is* for the given branch (perhaps by
name like "bibisect-repo_3.5"), or the bibisect repo *has* a branch in
it corresponding to the branch we're building?

> It is the responsibility of the buildbot maintainer to create new
> branches as needed (it is not trivial to automatically find the right
> branch point in bibisect)

By figuring out the branch point in bibisect, do you mean the point at
which we stop shoving builds into one bibisect repo (or branch in the
repo) and start shoving builds into a different bibisect repo (or
different branch)? Obviously it would be a big win for us to have
seamless coverage of commits -- so if I'm testing 3.6 beta, I can have
repos for bibisect-3.6-release, bibisect-3.5, etc... as far back as I
want to go, and have certainty that there are no gaps in commits
between these repositories. It seems to me that a pretty sane
mechanism for chunking up the bibisect repositories would be to keep
bibisect repositories of all of the builds on master, and then make
copies of these repositories so they can be used on the release
branches for specific versions, i.e.:

bibisect-3.5 would contain all builds from master until the 3.5 branch point.
bibisect-3.5-release would contain bibisect-3.5 plus all builds done
on the 3.5 branch.
bibisect-3.6 would contain all builds from master between bibisect-3.5
and the 3.6 branch point.
bibisect-3.6-release would contain bibisect-3.6 plus all builds done
on the 3.6 branch.
(etc...)

During testing, one could probably just get away with having the
-release repositories (there'd just be a little overlap of commits).

> 3/ the optional need to push to a remote bibisect repository.. that I
> have disable so far. There I think some code to be written to control
> when and how often this is done
> that is done in do_push()
> right now, git push manually  (or with a daily cron) will do the trick
> Note that not everyone that construct a bibisect repo necessarely want
> or can publish it to a remote repo

Yep, sounds good. I like the ability to run a tinderbox without it
pushing data/email externally.

> 4/ I've added some sanity check in tinbuild2, to detect upfront if -x
> is requested but ARTIFACTDIR is not set or is not a git repo (btw
> ARTIFACTDIR _has_ to be defined in config/$profile.cfg, since there is
> no good and safe default value for it (I accidentally ran the code
> with a default ARTIFACTDIR on my Mac it would have eventually blown-up
> my ramdisk and that could have taken a while before I noticed)

Fair enough. I'll mention that in the README or in the description of -x.

> Also: I tested it on Mac and it works just fine :-), next I'll try to
> check on my Windows tinderbox.. It it works fine, I'll deploy it on
> the ByteMark's windows tb.

So you got the Mac build work without mounting the dmgs? It looks like
you were able to dump all of the 'hdutil attach' bits, which sounds
great to me (the less platform-specific bits, the better!)

> FYI:
> the order of sourcing of files is:
> source tinbuild_internal.sh
> source tinbuild_internal_<OS>.sh
> source tinbuild_phases.sh
> source ~/.tinbuild/config/$profile.cfg
> source ~/.tinbuild/phases$profile.sh
> ...
> I mention that because I notice that in your setup/test stand-alone
> scripts(*) you are sourcing some of these and not in the intended
> order.

Ah, yes. I probably added parts to the test file at different times,
and didn't keep things in the right order. I'll sort that out and get
things in proper order.

> (*) which incidentally, I have not updated to reflect the changes in
> tinbuild2, so they are broken now :-)

No worries, I'll make sure they run and send a patch. Thanks for
getting all of this merged/refactored and for testing this on the mac!

--R