search

SeasideSt / Seaside

The framework for developing sophisticated web applications in Smalltalk.
MIT License
519 stars 71 forks source link

port Seaside to 3.7.0 #1249

Closed dalehenrich closed 3 years ago

dalehenrich commented 3 years ago

fix #1248 ... just needed an update to the baseline ..

jbrichau commented 3 years ago

Seems like 3.6.0 has consistent test failures. Not sure if you want me to merge it in right away or you want to hit the button yourself. I'll wait a little ;-)

dalehenrich commented 3 years ago

It was the 3.6.0 test that I wanted to rerun when I had simply created a new branch based off of master with no changes at all and the only change I've made here is to add 3.7, 3.8, and 3.9 to the baseline ... so something has changed on servers(?) to result in this consistent failure...

Not sure why the one test is failing for 3.6.0, since it doesn't fail locally ... the line where it is failing appears to be the statusGems report and that particular assertion is used in a number of of different GemServer tests that are run in the same test suite ... so it is a mystery compounded by the fact that in order to debug I cannot run just the 3.6.0 test ... and it doesn't seem that i have a private copy of the .yml test driver (at least I couldn't find a copy that I could edit) ... I'm guessing that it has to do with server loading ... but that's just one guess among many ... any advice on a way to proceed?

jbrichau commented 3 years ago

@dalehenrich seems like it did run in your fork: https://github.com/dalehenrich/Seaside/actions/runs/699767589

I'm guessing it's a spurious error and the chances were not on the right side when the tests ran. I'll retrigger this batch again.

jbrichau commented 3 years ago

@dalehenrich Given that all other tests are running just fine, it might just be a problem with the test itself that checks some output which might be different. I'm fine to merge this one in and take a look later at the failing test. At the very least, I don't think it's this PR that makes the test fail. Here is a run on another branch: https://github.com/SeasideSt/Seaside/actions/runs/690709165

dalehenrich commented 3 years ago

I've got some suspicions about the restartGem code and it's behavior on a heavily loaded machine ... I don't think that the stopGem code removes the pid file and if a gem was slow enough in getting started, the test could be looking for a process that has just died ... at least that's my suspicion ... thanks for merging !

dalehenrich commented 3 years ago

regarding the restartGem, the stop code DOES wait for the pid to go away and then it deletes the file ... so somethings else is afoot ...