Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

611 failures #354

Closed
wants to merge 2 commits into from
Closed

Conversation

mickaelistria
Copy link
Contributor

No description provided.

@github-actions
Copy link

github-actions bot commented Oct 12, 2022

Test Results

  87 files    87 suites   12m 14s ⏱️
885 tests 826 ✔️ 24 💤 17  18 🔥
942 runs  883 ✔️ 24 💤 17  18 🔥

For more details on these failures and errors, see this check.

Results for commit 7df1fb9.

♻️ This comment has been updated with latest results.

@merks
Copy link
Contributor

merks commented Jan 27, 2023

@iloveeclipse @HannesWell

I was revisiting the build failures with an eye to the API builder running a background job during tests. Here's what I see in the debugger:

image

I've set a breakpoint in org.eclipse.pde.api.tools.builder.tests.ApiBuilderTest.beforeClass() and set a conditional breakpoint in org.eclipse.pde.api.tools.internal.builder.ApiAnalysisBuilder.isRunningAsJob() stopped if it returns true. Here I have hit that conditional breakpoint but have not hit the beforeClass's breakpoint. That class is in the type hierarchy:

image

That method is sometimes called much later during other tests but I don't understand why it's sometimes called and not other times. In any case, it doesn't seem that we are reliably disabling the background builds.

If I hack org.eclipse.pde.api.tools.internal.builder.ApiAnalysisBuilder.isRunningAsJob() to return false always, the tests that are were failing then pass...

I think we need a better more reliable way to ensure the background job behavior is disabled...

@laeubi
Copy link
Contributor

laeubi commented Jan 27, 2023

It is just an idea, but probably one should not read the preferences always (what likley never change often in a real IDE anyways), but using a plain boolean field that can be set on the class?

One can then in the activator read the value from the prefs, set it in the class and update it on pref changes, if then the test sets the field also, one should be sure it is always in the right state (unless there is some code running that changes the preference value).

@laeubi
Copy link
Contributor

laeubi commented Jan 27, 2023

Also note that this particular testcase extends BuilderTests what is a Junit 3 Testcase so annotations won't work here. Instead of @BeforeClass one needs to override protected void setUp() (and call super method(!)).

@merks
Copy link
Contributor

merks commented Jan 27, 2023

Also note that this particular testcase extends BuilderTests what is a Junit 3 Testcase so annotations won't work here. Instead of @BeforeClass one needs to override protected void setUp() (and call super method(!)).

Very insightful!

@akurtakov
Copy link
Member

This went nowhere and there are other efforts to actually fix the issues.

@akurtakov akurtakov closed this Feb 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants