search

eclipse-pde / eclipse.pde

Eclipse Public License 2.0
25 stars 64 forks source link

Retry delete after a little delay / refresh in PDETestCase #1269

Closed laeubi closed 4 months ago

laeubi commented 4 months ago

Currently a failure to delete a project fails the test randomly on windows. This can be caused for example when things happen too fast and a file is still locked.

This first try the delete and if it fails wait one second, sync the project and if it still exits retry the delete.

Fix https://github.com/eclipse-pde/eclipse.pde/issues/1265

github-actions[bot] commented 4 months ago

Test Results

   291 files  ±0     291 suites  ±0   54m 20s :stopwatch: - 4m 13s  3 526 tests ±0   3 468 :white_check_mark: ±0   58 :zzz: ±0  0 :x: ±0  10 875 runs  ±0  10 698 :white_check_mark: ±0  177 :zzz: ±0  0 :x: ±0 

Results for commit ca4991ed. ± Comparison against base commit c2d4b0c1.

HeikoKlare commented 4 months ago

I guess that basically the same has to be done to fix #1264?

Since we have/had similar problems in the Eclipse platform itself, a central implementation for the workspace cleanup had been introduced in the WorkspaceTestRule. Maybe it makes sense to provide that functionality at some central place to be reused across projects and avoid isolated solutions?

laeubi commented 4 months ago

@HeikoKlare maybe yes, I just found that some instabilities are often only a timing issue, it would of course be great to have a JUnit5 Rule / Extension / ... that would encapsulate all these parts, for example we often have the demand to wait for Autobuild, disable autobuild, wait for jobs to finish and so on. @akurtakov might know if there is a good place to collect such things. The osgi-test project even goes a little further and even records what is done and undo the actions afterwards, I think something like this for a "Workspace" that has options to import / create projects would be nice so they automatically get cleaned up like for bundles / services in OSGi test.

HeikoKlare commented 4 months ago

Great, thank you for that input! I will keep that in mind when proceeding with the JUnit 5 migration in the platform. The existing rules are rather limited in terms of reusability (as being placed in specific test plug-ins), but having reusable (JUnit 5) extensions for workspace-setup/cleanup-related tasks will make sense anyway.