Re: Offering GHC builder build slaves

2014-04-09 0:25 GMT+02:00 Lyndon Nerenberg
Is there any way to verify that builder-client can actually do a successful build, without having access to the build system server? 'builder-client --do-build' wants to connect and authenticate first; it would be helpful if there was a way to bypass that so that I can first verify the local build environment is sane.
This is because the builder client gets the commands to be executed from the server. A naive solution would be to put the commands in the script and run it. You can find the current set of installed commands at one of the active builders page, e.g. [1]. Note that you may have to change some of them, such as the flags passed to configure script and name of the make(1) command. [1] http://haskell.inf.elte.hu/builders/solaris-x86-head/23.html

On 04/10/2014 12:12 AM, Páli Gábor János wrote:
2014-04-09 0:25 GMT+02:00 Lyndon Nerenberg
: Is there any way to verify that builder-client can actually do a successful build, without having access to the build system server? 'builder-client --do-build' wants to connect and authenticate first; it would be helpful if there was a way to bypass that so that I can first verify the local build environment is sane.
This is because the builder client gets the commands to be executed from the server. A naive solution would be to put the commands in the script and run it.
You can find the current set of installed commands at one of the active builders page, e.g. [1]. Note that you may have to change some of them, such as the flags passed to configure script and name of the make(1) command.
[1] http://haskell.inf.elte.hu/builders/solaris-x86-head/23.html _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Just to revive this thread a bit, I notice that the builds with failing test results are still marked as successful. Would it not be useful to indicate that there are failing tests somehow? It'd be a shame to have various test results from multiple machines but not use them. -- Mateusz K.

2014-06-07 0:17 GMT+02:00 Mateusz Kowalczyk
I notice that the builds with failing test results are still marked as successful. Would it not be useful to indicate that there are failing tests somehow?
The result is based on the value that the invoked command returns. That is, for the testing phase, the "make test BINDIST=YES" command returned ExitSuccess, that is why it is marked green.
It'd be a shame to have various test results from multiple machines but not use them.
I see what you mean. But I would also feel strange to mark the test results failed if only a few of them fail. Note that the testsuite summaries are forwarded to the ghc-builds mailing list so they are published and archived.

Hi, Am Samstag, den 07.06.2014, 12:21 +0200 schrieb Páli Gábor János:
2014-06-07 0:17 GMT+02:00 Mateusz Kowalczyk
: It'd be a shame to have various test results from multiple machines but not use them.
I see what you mean. But I would also feel strange to mark the test results failed if only a few of them fail. Note that the testsuite summaries are forwarded to the ghc-builds mailing list so they are published and archived.
ideally, these would be collected in a meaningful way, so that one can see „Commit 123 changed the number of failing tests from 2 to 3“ or „Test T1234 fails since 1.1.2014“ or so. Ideally together with performance numbers („This commit improved nofib by x%“) and nice graphs. It must be possible to collect and present such results that without reinventing the wheel, I just haven’t seen such a tool yet. (And I know that „we should have X“ mails are not very useful...) Greetings from Zürich, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
participants (3)
-
Joachim Breitner
-
Mateusz Kowalczyk
-
Páli Gábor János