[ Pharo 70 ] Build 52 to 54

Hi Marcus,

Please, do not relaunch the build if there is a test failure. That
simply does not fix the problem, it just adds noise. There are two
problems:

1) we have some sporadic test failures (sometimes network, sometimes
some mutex or delay issues). They do not happen all the time and
that's why sometimes there is one or two failing tests. We should
detect these tests and fix them to be more robust

   >> Note, is there some brave soul that would like to take action here?

2) sometimes the vm crashes while running the tests. We should detect
the bug and fix it.

   >> Note, is there some brave soul that would like to take action here?

Now, if we are integrating a fix, this means that the PR was **already
validated as green**. That means that the integrated commit can be
bootstrapped and tested (and all tests are green).

Moreover, running the tests after integration (and its build color)
does not change the integration in itself: the commit was already
merged and pushed into the main branch, so even if it fails always,
it's too late. So, relaunching the build does not really change
anything (besides the impression we may have about the build).

A complementary solution (that should go together with fixing the
tests) is to add a retry policy while running tests in the CI.

   >> Note, is there some brave soul that would like to take action here?

Guille, on holidays from the phone.

On 8/22/17, Marcus Denker <[hidden email]> wrote:
> [ Pharo 70 ] Build 52 PR 205
> index-inst-var-should-move-from-Slot-to-IndexedSlot
>       https://github.com/pharo-project/pharo/pull/205
>       https://pharo.fogbugz.com/f/cases/20191
>
>  Build 53: failed, redone as 54
>
> [ Pharo 70 ] Build 54 PR 193 Integrate WebBrowser-Core package to be able to
> open a browser on a URL
>       https://pharo.fogbugz.com/f/cases/20304
>       https://github.com/pharo-project/pharo/pull/193
>
>  Build 55: failed, redone as 56 (I do not like to use this build number…
> with builds failing, we will always get the
> question “and what was in build XX?).
>
> [ Pharo 70 ] Build 56 PR 174
> 20260-FastTable-not-support-cell-morphs-with-stepping-animation #174
>       https://github.com/pharo-project/pharo/pull/174
> https://pharo.fogbugz.com/f/cases/20260/
>
>
>

--




Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*
<http://www.cnrs.fr>



*Web:* *http://guillep.github.io* <http://guillep.github.io>

*Phone: *<a href="tel:%2B33%2006%2052%2070%2066%2013" value="+33652706613">+33 06 52 70 66 13

Hi Marcus,

Please, do not relaunch the build if there is a test failure. That
simply does not fix the problem, it just adds noise. There are two
problems:

1) we have some sporadic test failures (sometimes network, sometimes
some mutex or delay issues). They do not happen all the time and
that's why sometimes there is one or two failing tests. We should
detect these tests and fix them to be more robust

   >> Note, is there some brave soul that would like to take action here?

2) sometimes the vm crashes while running the tests. We should detect
the bug and fix it.

   >> Note, is there some brave soul that would like to take action here?

Now, if we are integrating a fix, this means that the PR was **already
validated as green**. That means that the integrated commit can be
bootstrapped and tested (and all tests are green).

Moreover, running the tests after integration (and its build color)
does not change the integration in itself: the commit was already
merged and pushed into the main branch, so even if it fails always,
it's too late.

So, relaunching the build does not really change
anything (besides the impression we may have about the build).

A complementary solution (that should go together with fixing the
tests) is to add a retry policy while running tests in the CI.

   >> Note, is there some brave soul that would like to take action here?

Guille, on holidays from the phone.

On 8/22/17, Marcus Denker <[hidden email]> wrote:
> [ Pharo 70 ] Build 52 PR 205
> index-inst-var-should-move-from-Slot-to-IndexedSlot
>       https://github.com/pharo-project/pharo/pull/205
>       https://pharo.fogbugz.com/f/cases/20191
>
>  Build 53: failed, redone as 54
>
> [ Pharo 70 ] Build 54 PR 193 Integrate WebBrowser-Core package to be able to
> open a browser on a URL
>       https://pharo.fogbugz.com/f/cases/20304
>       https://github.com/pharo-project/pharo/pull/193
>
>  Build 55: failed, redone as 56 (I do not like to use this build number…
> with builds failing, we will always get the
> question “and what was in build XX?).
>
> [ Pharo 70 ] Build 56 PR 174
> 20260-FastTable-not-support-cell-morphs-with-stepping-animation #174
>       https://github.com/pharo-project/pharo/pull/174
> https://pharo.fogbugz.com/f/cases/20260/
>
>
>

--




Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*
<http://www.cnrs.fr>



*Web:* *http://guillep.github.io* <http://guillep.github.io>

*Phone: *<a href="tel:%2B33%2006%2052%2070%2066%2013" value="+33652706613">+33 06 52 70 66 13

On Tue, Aug 22, 2017 at 11:51 PM, Guillermo Polito <[hidden email]> wrote:

Hi Marcus,

Please, do not relaunch the build if there is a test failure. That
simply does not fix the problem, it just adds noise. There are two
problems:

1) we have some sporadic test failures (sometimes network, sometimes
some mutex or delay issues). They do not happen all the time and
that's why sometimes there is one or two failing tests. We should
detect these tests and fix them to be more robust

   >> Note, is there some brave soul that would like to take action here?

2) sometimes the vm crashes while running the tests. We should detect
the bug and fix it.

   >> Note, is there some brave soul that would like to take action here?

Now, if we are integrating a fix, this means that the PR was **already
validated as green**. That means that the integrated commit can be
bootstrapped and tested (and all tests are green).

Moreover, running the tests after integration (and its build color)
does not change the integration in itself: the commit was already
merged and pushed into the main branch, so even if it fails always,
it's too late.

I thought the idea of CI was to merge into the main branch *after* the tests pass.

Why is the PR-branch not checked out to run the tests on...?

   https://help.github.com/articles/checking-out-pull-requests-locally/

 

cheers -ben