Thank you all for your feedback - so let's do it with a TestCase added into
the image.
PR is available, according CI is green and ready for review/integration:
https://github.com/pharo-project/pharo/pull/1782
Hi, I don't think that 20 seconds will affect the overall process :). It
will only become a problem if we increment the number of these kind of
tests by *a lot*...
Another solution is to make some tests run in parallel. But for this to run
properly we have to increase the number of slaves in Jenki
On Thu, 6 Sep 2018 at 23:06, Cyril Ferlicot D. wrote:
>
>
> Maybe we could have a package with release tests that are not executed
> by the CI but that are executed at the moment of the feature freeze and
> some time before the Pharo release to ensure the quality of the code
> base for tests that
In my experience this is not a good idea. When you're in the pressure of
the release the last thing you want it's to fix things that shouldn't be
merged in that form. It sends the wrong message to the people contributing,
If you have this fail in your own PR you can easily fix it and learn for
it
Le 06/09/2018 à 17:50, Torsten Bergmann a écrit :
> Hi,
>
> the very nice contribution on GIFReadWriter/animated images (see
> https://pharo.manuscript.com/f/cases/22137)
> unfortunately introduced some methods that had no sender, were uncategorized
> and had unused temporary variables, etc.
>
Hi Torsten,
We experienced some similar problems with our builds at Mercap, because all
the tests involving code analysis are orders of magnitude slower than the
unit tests. What we do is:
- When the programmer closes a unit of work (in that case it will be
equivalent to create a PR) we run the tes
Hi,
the very nice contribution on GIFReadWriter/animated images (see
https://pharo.manuscript.com/f/cases/22137)
unfortunately introduced some methods that had no sender, were uncategorized
and had unused temporary variables, etc.
Something that is meanwhile shown by our tools and easy to fix.
