* [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).