diff mbox

guxi: cmake-build-system: Enable output for failing test-cases.

Message ID 1476104563-29373-1-git-send-email-h.goebel@crazy-compilers.com
State New
Headers show

Commit Message

Hartmut Goebel Oct. 10, 2016, 1:02 p.m. UTC
* guix/build/cmake-build-system.scm (cmake-build-system): Set
  environment variable CTEST_OUTPUT_ON_FAILURE to an non-empty value.
---
 guix/build/cmake-build-system.scm | 1 +
 1 file changed, 1 insertion(+)

Comments

Ludovic Courtès Oct. 13, 2016, 8:12 p.m. UTC | #1
Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> * guix/build/cmake-build-system.scm (cmake-build-system): Set
>   environment variable CTEST_OUTPUT_ON_FAILURE to an non-empty value.

It’s a good idea, but it would entail a rebuild of 1,000+ packages.  Can
you save it for the next big-rebuild cycle?

Thanks,
Ludo’.
Hartmut Goebel Oct. 14, 2016, 7:56 a.m. UTC | #2
Am 13.10.2016 um 22:12 schrieb Ludovic Courtès:
> It’s a good idea, but it would entail a rebuild of 1,000+ packages.  Can
> you save it for the next big-rebuild cycle?

No problem.

Still have to learn what "next big-rebuild cycle" means. Is there a
branch for it?
Ludovic Courtès Oct. 17, 2016, 8:14 p.m. UTC | #3
Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> Am 13.10.2016 um 22:12 schrieb Ludovic Courtès:
>> It’s a good idea, but it would entail a rebuild of 1,000+ packages.  Can
>> you save it for the next big-rebuild cycle?
>
> No problem.
>
> Still have to learn what "next big-rebuild cycle" means. Is there a
> branch for it?

Not really!

Well there’s core-updates for changes that trigger a rebuild of 90% of
the packages, and then occasionally topic branches (‘python-updates’,
etc.)

Once ‘core-updates’ is merged (hopefully in a few days), we could start
a ‘staging’ branch and put changes that require between ~300 and ~1200
rebuilds.  The idea would be to close the branch much more quickly than
core-updates (the changes should be less disruptive, with little chance
of breaking things.)

Ludo’.
Hartmut Goebel Oct. 18, 2016, 7:46 a.m. UTC | #4
Am 17.10.2016 um 22:14 schrieb Ludovic Courtès:
> Once ‘core-updates’ is merged (hopefully in a few days), we could start
> a ‘staging’ branch and put changes that require between ~300 and ~1200
> rebuilds.  The idea would be to close the branch much more quickly than
> core-updates (the changes should be less disruptive, with little chance
> of breaking things.)

This is a good idea, too.

I meant some branch like "core-updates-next", as a staging branch for
the next "core-updates" cycle, too. So if he core-updates are currently
build, we most likely do not want to tough it. But we could already push
some changes to core-updates next to get them off our todo-lists.

But maybe this is just what you call "staging" branch :-)
Ludovic Courtès Oct. 18, 2016, 12:41 p.m. UTC | #5
Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> Am 17.10.2016 um 22:14 schrieb Ludovic Courtès:
>> Once ‘core-updates’ is merged (hopefully in a few days), we could start
>> a ‘staging’ branch and put changes that require between ~300 and ~1200
>> rebuilds.  The idea would be to close the branch much more quickly than
>> core-updates (the changes should be less disruptive, with little chance
>> of breaking things.)
>
> This is a good idea, too.
>
> I meant some branch like "core-updates-next", as a staging branch for
> the next "core-updates" cycle, too. So if he core-updates are currently
> build, we most likely do not want to tough it. But we could already push
> some changes to core-updates next to get them off our todo-lists.
>
> But maybe this is just what you call "staging" branch :-)

Yes.  To summarize:

| name           | rebuilds       | merge frequency | type                          |
|----------------+----------------+-----------------+-------------------------------|
| core-updates   | > 1200         | 2.5 months      | possibly disruptive           |
| staging        | 300 < n < 1200 | 3 weeks         | non-disruptive                |
| master         | < 300          | n/a             | non-disruptive                |
| $TOPIC-updates | > 300          | when it's ready | topic-specific (e.g., Python) |

Of course this depends on the power of our build farm and on how
disciplined we are.  ;-)  That is, we should pay attention to the status
of these branches on Hydra, fix issues in a timely fashion, and merge
them as soon as they're almost entirely built.

What do people think?

Ludo'.
Leo Famulari Nov. 15, 2016, 9:13 p.m. UTC | #6
On Thu, Oct 13, 2016 at 10:12:01PM +0200, Ludovic Courtès wrote:
> Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:
> 
> > * guix/build/cmake-build-system.scm (cmake-build-system): Set
> >   environment variable CTEST_OUTPUT_ON_FAILURE to an non-empty value.
> 
> It’s a good idea, but it would entail a rebuild of 1,000+ packages.  Can
> you save it for the next big-rebuild cycle?

Hartmut, can you push this to the recently created "staging" branch?
Hartmut Goebel Nov. 15, 2016, 9:44 p.m. UTC | #7
Am 15.11.2016 um 22:13 schrieb Leo Famulari:
> Hartmut, can you push this to the recently created "staging" branch?
Done.
diff mbox

Patch

diff --git a/guix/build/cmake-build-system.scm b/guix/build/cmake-build-system.scm
index f57622e..27f2b5c 100644
--- a/guix/build/cmake-build-system.scm
+++ b/guix/build/cmake-build-system.scm
@@ -66,6 +66,7 @@ 
 (define* (check #:key (tests? #t) (parallel-tests? #t) (test-target "test")
                 #:allow-other-keys)
   (let ((gnu-check (assoc-ref gnu:%standard-phases 'check)))
+    (setenv "CTEST_OUTPUT_ON_FAILURE" "1")
     (gnu-check #:tests? tests? #:test-target test-target
               #:parallel-tests? parallel-tests?)))