argh, tests are failing!
Locked
12
12
argh, tests are failing!
Re: argh, tests are failing!
 
|
Of course you are right, the Integrators should really take care on it. Before it were only common random failures but the main problem is with this PR: The new test testHashMethodNeedsToBeInComparingProtocol fails on classIceSemanticVersion -- Pavel 2017-09-10 10:13 GMT+02:00 Guillermo Polito <[hidden email]>:
|
Re: argh, tests are failing!
|
|
Yes we know but have no idea how to recategorise Iceberg protocols On Sun, Sep 10, 2017 at 1:03 PM, Pavel Krivanek <[hidden email]> wrote:
|
Re: argh, tests are failing!
|
|
Give me a system that I can fully change and you will see less trivial failing tests :) On Sun, Sep 10, 2017 at 6:24 PM, Stephane Ducasse <[hidden email]> wrote:
|
Re: argh, tests are failing!
|
|
In reply to this post by Stephane Ducasse-3
Le 10/09/2017 à 18:24, Stephane Ducasse a écrit :
> Yes we know but have no idea how to recategorise Iceberg protocols > The protocol is already recategorised in Iceberg dev branch. Now we need a new stable release of Iceberg and to integrated this release in Pharo. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France |
signature.asc (836 bytes)
Re: argh, tests are failing!
|
|
Re: argh, tests are failing!
|
|
Re: argh, tests are failing!
|
|
In reply to this post by Guillermo Polito
Hi, I have checked the EventRecorderTests and it works on my computer. The only reason that it might not work on other cases is that there an assert for 'semaphore waitTimeoutMSecs: 200’. I can put higher timeout if necessary. The timeout 200 has worked for couple of years, right?. There might be another issue. Cheers, Juraj
|
Re: argh, tests are failing!
|
|
Re: argh, tests are failing!
|
|
Re: argh, tests are failing!
|
|
Re: argh, tests are failing!
|
|
In reply to this post by Guillermo Polito
I will take a look into Mutex 2017-09-10 10:13 GMT+02:00 Guillermo Polito <[hidden email]>:
|
Re: argh, tests are failing!
|
|
In reply to this post by Juraj Kubelka
Hi Juraj, think that it may really depend on the machine and the state of the system. Slower slave machines could not really work with that timeout... The question is how could we make such test more robust. On Sun, Sep 10, 2017 at 6:41 PM, Juraj Kubelka <[hidden email]> wrote:
|
Re: argh, tests are failing!
|
|
In reply to this post by Torsten Bergmann
On Sun, Sep 10, 2017 at 7:16 PM, Torsten Bergmann <[hidden email]> wrote: Hi, Yes yes, I can't agree more. We need to add Lint rules running by default also.
Yep, this should be fixed as soon as we have multiple subdirectories/subprojects in iceberg. As soon as that is supported we will probably move iceberg to a subtree structure as explained in here: https://github.com/guillep/PharoIntegrationProcess/wiki/Analysis-of-sub-project-storage-alternatives
While the test is an improvement over the current situation, I ask myself if this particular validation of the protocols shouldn't be a Renraku rule.
As Pavel said, the iceberg version that is included in the system is the one described in BaselineOfIDE >> loadIceberg Metacello new baseline: 'Iceberg'; repository: 'github://pharo-vcs/iceberg:v0.5.7'; load. (Smalltalk classNamed: #Iceberg) enableMetacelloIntegration: true. So updating that method with the new iceberg version and pushing that to Pharo should be enough. In any case, my mail was there just to raise the issue of the failing tests. We should care about failing tests, and I'll cry out loud everytime they are broken, just to make it explicit.
|
Re: argh, tests are failing!
|
|
In reply to this post by Denis Kudriashov
Thanks Denis On Mon, Sep 11, 2017 at 11:35 AM, Denis Kudriashov <[hidden email]> wrote:
|
Re: argh, tests are failing!
|
|
In reply to this post by Stephane Ducasse-3
On Mon, Sep 11, 2017 at 7:19 AM, Stephane Ducasse <[hidden email]> wrote: Hi torsten Yes, that's what I described in ESUG too :) On the way back from ESUG we discussed with Esteban a way to support this kind of scenarios cleanly and without needing too much of a refactor ;)
|
Re: argh, tests are failing!
|
|
In reply to this post by Guillermo Polito
2017-09-11 12:07 GMT+02:00 Guillermo Polito <[hidden email]>:
I will try to prepare a small tool that will collect information about health status of a build that will be stored as a STON file next to the image (at least for the development versions). Then we can generate the same information about incoming PRs and display changes. This way we will be able to see effects of the PR like what new dependencies it added, what new rules are failing and so on. It should not reject then automatically but to be a support for the PR review. -- Pavel
|
Re: argh, tests are failing!
|
|
Re: argh, tests are failing!
|
|
In reply to this post by Guillermo Polito
Hi Guillermo, I have not found better solution. Waiting without a timeout threshold is not nice and makes it difficult to run all tests. If you have better idea how to sync and test two processes, I will appreciate it. Otherwise I will use a higher timeout. Cheers, Juraj
|
Re: argh, tests are failing!
|
|
But the thing is that those processes you are creating for delivery are running in priority 30. This means that it may happen that they may not run any time soon (even those 200ms) if there are processes scheduled with higher priorities. So, the thing is that test is not a unit test at all. It depends a lot on the running environment. Solutions for that: - you change the priority of the delivery process for test purposes - Or, for testing purposes you don't create a new process, you just execute synchronously If you want really to test the fact that you are creating and running a separate process, then you should also try to let explicit the processes you created run. This means, if the active process that is running the tests (usually priority 40) does not suspend itself, no processes of priority 30 will be able to run. Ways to suspend the active process and let lower priority ones run are: - calling suspend (Processor activeProcess suspend) but this is dangerous because somebody should resume it afterwards from a separate process - using a delay - some I/O like sockets or async files On Mon, Sep 11, 2017 at 7:40 PM, Juraj Kubelka <[hidden email]> wrote:
|
| Free forum by Nabble | Edit this page |