unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [PATCH] guxi: cmake-build-system: Enable output for failing test-cases.
@ 2016-10-10 13:02 Hartmut Goebel
  2016-10-13 20:12 ` Ludovic Courtès
  0 siblings, 1 reply; 8+ messages in thread
From: Hartmut Goebel @ 2016-10-10 13:02 UTC (permalink / raw)
  To: guix-devel

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

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?)))
 
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] guxi: cmake-build-system: Enable output for failing test-cases.
  2016-10-10 13:02 [PATCH] guxi: cmake-build-system: Enable output for failing test-cases Hartmut Goebel
@ 2016-10-13 20:12 ` Ludovic Courtès
  2016-10-14  7:56   ` Hartmut Goebel
  2016-11-15 21:13   ` [PATCH] guxi: cmake-build-system: Enable output for failing test-cases Leo Famulari
  0 siblings, 2 replies; 8+ messages in thread
From: Ludovic Courtès @ 2016-10-13 20:12 UTC (permalink / raw)
  To: Hartmut Goebel; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] guxi: cmake-build-system: Enable output for failing test-cases.
  2016-10-13 20:12 ` Ludovic Courtès
@ 2016-10-14  7:56   ` Hartmut Goebel
  2016-10-17 20:14     ` Ludovic Courtès
  2016-11-15 21:13   ` [PATCH] guxi: cmake-build-system: Enable output for failing test-cases Leo Famulari
  1 sibling, 1 reply; 8+ messages in thread
From: Hartmut Goebel @ 2016-10-14  7:56 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

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?

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] guxi: cmake-build-system: Enable output for failing test-cases.
  2016-10-14  7:56   ` Hartmut Goebel
@ 2016-10-17 20:14     ` Ludovic Courtès
  2016-10-18  7:46       ` Hartmut Goebel
  0 siblings, 1 reply; 8+ messages in thread
From: Ludovic Courtès @ 2016-10-17 20:14 UTC (permalink / raw)
  To: Hartmut Goebel; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] guxi: cmake-build-system: Enable output for failing test-cases.
  2016-10-17 20:14     ` Ludovic Courtès
@ 2016-10-18  7:46       ` Hartmut Goebel
  2016-10-18 12:41         ` Branching and rebuild scheduling strategy Ludovic Courtès
  0 siblings, 1 reply; 8+ messages in thread
From: Hartmut Goebel @ 2016-10-18  7:46 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

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

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Branching and rebuild scheduling strategy
  2016-10-18  7:46       ` Hartmut Goebel
@ 2016-10-18 12:41         ` Ludovic Courtès
  0 siblings, 0 replies; 8+ messages in thread
From: Ludovic Courtès @ 2016-10-18 12:41 UTC (permalink / raw)
  To: Hartmut Goebel; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] guxi: cmake-build-system: Enable output for failing test-cases.
  2016-10-13 20:12 ` Ludovic Courtès
  2016-10-14  7:56   ` Hartmut Goebel
@ 2016-11-15 21:13   ` Leo Famulari
  2016-11-15 21:44     ` Hartmut Goebel
  1 sibling, 1 reply; 8+ messages in thread
From: Leo Famulari @ 2016-11-15 21:13 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] guxi: cmake-build-system: Enable output for failing test-cases.
  2016-11-15 21:13   ` [PATCH] guxi: cmake-build-system: Enable output for failing test-cases Leo Famulari
@ 2016-11-15 21:44     ` Hartmut Goebel
  0 siblings, 0 replies; 8+ messages in thread
From: Hartmut Goebel @ 2016-11-15 21:44 UTC (permalink / raw)
  To: Leo Famulari, Ludovic Courtès; +Cc: guix-devel

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

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2016-11-15 21:44 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-10 13:02 [PATCH] guxi: cmake-build-system: Enable output for failing test-cases Hartmut Goebel
2016-10-13 20:12 ` Ludovic Courtès
2016-10-14  7:56   ` Hartmut Goebel
2016-10-17 20:14     ` Ludovic Courtès
2016-10-18  7:46       ` Hartmut Goebel
2016-10-18 12:41         ` Branching and rebuild scheduling strategy Ludovic Courtès
2016-11-15 21:13   ` [PATCH] guxi: cmake-build-system: Enable output for failing test-cases Leo Famulari
2016-11-15 21:44     ` Hartmut Goebel

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).