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

* 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(+)

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’.

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?

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’.

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 :-)

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'.

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?

Am 15.11.2016 um 22:13 schrieb Leo Famulari:
> Hartmut, can you push this to the recently created "staging" branch?
Done.