On Fri, Feb 14, 2014 at 6:49 PM, Ben Reser <ben_at_reser.org> wrote:
> We need our buildbots to work for branches. I propose the following
> changes,
> in decreasing order of priority.
>
> 1) If something like bindings is broken on a build bot for branches then
> disable the test on that buildbot. It is far better to disable bindings
> tests
> than it is to continue to allow the build bot to fail and thus encourage
> us to
> ignore the build bot entirely.
>
> 2) We should find a way to keep functioning build slaves for our branches
> that
> support the same tests as we run for trunk. If that means providing
> parallel
> installations of dependencies on the same machine or using separate
> machines
> then we should do that.
>
> 3) The build bot should not use the same slave for builds of branch and
> trunk
> changes. Right now the waterfall view does not give you a good view of the
> state of our branches/trunk. If I break 1.7.x the bot will show red until
> the
> next build which might be on trunk succeeds. That's not useful. I can
> understand sometimes running a test on a branch that's not normally tested
> (like I did with the 1.7.x-diff-translate branch) and using the 1.7.x
> slave.
> But we really ought to have slaves for each release branch we're using.
>
> Obviously 2 and 3 are longer term propositions. But #1 is something we
> should
> fix immediately. To that end I have conducted an audit of what's broken on
> which build bots and which release branches. My findings are below.
>
> 1.8.x:
> svn-x64-ubuntu-gcc: works
> svn-x64-centos-gcc: works
> bb-openbsd: doesn't build 1.8.x
> svn-windows-local: JavaHL fails.
> svn-windows-ra: Perl bindings fails.
>
> 1.7.x:
> svn-x64-ubuntu-gcc: Ruby bindings fail (build not just tests)
> svn-x64-centos-gcc: works
> bb-openbsd: doesn't build 1.8.x
> svn-windows-local: JavaHL fails.
> svn-windows-ra: Build fails (can't determine why bot is down right now).
>
> We should disable the swig-rb tests on 1.7.x on svn-x864-ubuntu-gcc since
> the
> problem there is that the version of Ruby on that host is too new for
> 1.7.x.
>
> Bert said the JavaHL tests on svn-windows-local are known due to some sort
> of
> DLL PATH problem. We should fix or disable these.
>
> I recall Bert having said in the past that SWIG-PL doesn't build on Windows
> properly, we should disable that test for swig-windows-ra.
>
> The build bots are down for Windows right now due to a network issue. So I
> can't run a specific test to determine what's wrong with svn-windows-ra and
> 1.7.x and the logs for the old builds have been removed already.
>
> We have two ways to handle turning tests off by branch. First we can pass
> the
> branch into the scripts that it's running for and then turn things off.
> The
> only problem with this is that svncheck.sh for the *nix buildbots already
> takes
> the list of tests to run. So we'll need to change the scripts to accept
> this
> in parallel with the master changes to pass it. We could alternatively
> detect
> the branch from the working copy. But I'm not sure how easy this will be
> to do.
>
> Or we could just skip all of the above and get the build bots setup with
> separate slaves for each branch and then they can have their own
> independent
> scripts.
>
> I'd start on some of the above steps but I'm also not clear on how these
> scripts get updated on the slaves. Does someone have to do that manually,
> are
> they automatically updated? If they are manually updated are the current
>
I know that on the svn-x64-ubuntu-gcc slave (currently residing in my
basement), the scripts are updated manually. I may even have local edits
that aren't yet in the repository.
> versions in SVN? For that matter is there someplace where we document
> exactly
> who is responsible for which slaves?
>
+1 to documenting who owns what.
Received on 2014-02-17 21:38:44 CET