Having green builds

Hi all,

As you all know, we are now building from github. Integrations are made through pull requests. And pull requests are validated using jenkins (that is back again, Yay!).

In this scenario, pull requests validations in github differentiate only between three states: Pased (green) and not passed (red). This of course conflicts with the three-state jobs of jenkins. By default jenkins transforms failing tests (yellow) to a red state. This means that we lose the extra information provided by the intermediate state.

Now, because of this, in order to really differentiate good builds from bad builds, we need to have green builds :). Always.

Yesterday we worked with Pablo on that and now we have a PR that fixes all tests and is green :)

https://github.com/pharo-project/pharo/pull/184

You can follow up all the things we did in the issue also:

https://pharo.fogbugz.com/f/cases/20288/Fix-failing-tests-in-pharo-70

As a summary, we could fix most tests by just touching some code here and there. Some of them were portability issues, some other encoding in the build slaves and so on. The only one we could not fix was a problem cause by a side effect of QualityAssistant-Tests, so we skipped it. Those two tests should be rewritten to not have side effects on other tests (In this case, Epicea).

Enjoy,

Guille and Pablo

--

Guille Polito Research Engineer French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

Hi all,

As you all know, we are now building from github. Integrations are made through pull requests. And pull requests are validated using jenkins (that is back again, Yay!).

In this scenario, pull requests validations in github differentiate only between three states: Pased (green) and not passed (red). This of course conflicts with the three-state jobs of jenkins. By default jenkins transforms failing tests (yellow) to a red state. This means that we lose the extra information provided by the intermediate state.

Now, because of this, in order to really differentiate good builds from bad builds, we need to have green builds :). Always.

Yesterday we worked with Pablo on that and now we have a PR that fixes all tests and is green :)

https://github.com/pharo-project/pharo/pull/184

You can follow up all the things we did in the issue also:

https://pharo.fogbugz.com/f/cases/20288/Fix-failing-tests-in-pharo-70

As a summary, we could fix most tests by just touching some code here and there. Some of them were portability issues, some other encoding in the build slaves and so on. The only one we could not fix was a problem cause by a side effect of QualityAssistant-Tests, so we skipped it. Those two tests should be rewritten to not have side effects on other tests (In this case, Epicea).

Enjoy,

Guille and Pablo

--

Guille Polito Research Engineer French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

Hi all,

As you all know, we are now building from github. Integrations are made through pull requests. And pull requests are validated using jenkins (that is back again, Yay!).

In this scenario, pull requests validations in github differentiate only between three states: Pased (green) and not passed (red). This of course conflicts with the three-state jobs of jenkins. By default jenkins transforms failing tests (yellow) to a red state. This means that we lose the extra information provided by the intermediate state.

Now, because of this, in order to really differentiate good builds from bad builds, we need to have green builds :). Always.

Yesterday we worked with Pablo on that and now we have a PR that fixes all tests and is green :)

https://github.com/pharo-project/pharo/pull/184

You can follow up all the things we did in the issue also:

https://pharo.fogbugz.com/f/cases/20288/Fix-failing-tests-in-pharo-70

As a summary, we could fix most tests by just touching some code here and there. Some of them were portability issues, some other encoding in the build slaves and so on. The only one we could not fix was a problem cause by a side effect of QualityAssistant-Tests, so we skipped it. Those two tests should be rewritten to not have side effects on other tests (In this case, Epicea).

Enjoy,

Guille and Pablo

--

Guille Polito Research Engineer French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: +33 06 52 70 66 13

Hi all,

As you all know, we are now building from github. Integrations are made through pull requests. And pull requests are validated using jenkins (that is back again, Yay!).

In this scenario, pull requests validations in github differentiate only between three states: Pased (green) and not passed (red). This of course conflicts with the three-state jobs of jenkins. By default jenkins transforms failing tests (yellow) to a red state. This means that we lose the extra information provided by the intermediate state.

Now, because of this, in order to really differentiate good builds from bad builds, we need to have green builds :). Always.

Yesterday we worked with Pablo on that and now we have a PR that fixes all tests and is green :)

https://github.com/pharo-project/pharo/pull/184

You can follow up all the things we did in the issue also:

https://pharo.fogbugz.com/f/cases/20288/Fix-failing-tests-in-pharo-70

As a summary, we could fix most tests by just touching some code here and there. Some of them were portability issues, some other encoding in the build slaves and so on. The only one we could not fix was a problem cause by a side effect of QualityAssistant-Tests, so we skipped it. Those two tests should be rewritten to not have side effects on other tests (In this case, Epicea).

Enjoy,

Guille and Pablo

--

Guille Polito Research Engineer French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13