master fails

[jukzi]

and nobody cares.

https://ci.eclipse.org/platform/job/eclipse.platform.ui/job/master/

11:04:25.794 [ERROR] Failed to execute goal org.eclipse.tycho:tycho-apitools-plugin:4.0.6-SNAPSHOT:verify (verify) on project org.eclipse.jface: There are API errors:
11:04:25.794 [ERROR] META-INF/MANIFEST.MF:0 The re-exported type org.eclipse.swt.ole.win32.OLE has been removed from org.eclipse.jface_3.32.0
11:04:25.795 [ERROR] META-INF/MANIFEST.MF:0 The re-exported type org.eclipse.swt.ole.win32.OleAutomation has been removed from org.eclipse.jface_3.32.0
11:04:25.795 [ERROR] META-INF/MANIFEST.MF:0 The re-exported type org.eclipse.swt.ole.win32.OleClientSite has been removed from org.eclipse.jface_3.32.0
11:04:25.795 [ERROR] META-INF/MANIFEST.MF:0 The re-exported type org.eclipse.swt.ole.win32.OleControlSite has been removed from org.eclipse.jface_3.32.0
11:04:25.795 [ERROR] META-INF/MANIFEST.MF:0 The re-exported type org.eclipse.swt.ole.win32.OleEvent has been removed from org.eclipse.jface_3.32.0
11:04:25.795 [ERROR] META-INF/MANIFEST.MF:0 The re-exported type org.eclipse.swt.ole.win32.OleFrame has been removed from org.eclipse.jface_3.32.0
11:04:25.795 [ERROR] META-INF/MANIFEST.MF:0 The re-exported type org.eclipse.swt.ole.win32.OleFunctionDescription has been removed from org.eclipse.jface_3.32.0
11:04:25.795 [ERROR] META-INF/MANIFEST.MF:0 The re-exported type org.eclipse.swt.ole.win32.OleListener has been removed from org.eclipse.jface_3.32.0
11:04:25.795 [ERROR] META-INF/MANIFEST.MF:0 The re-exported type org.eclipse.swt.ole.win32.OleParameterDescription has been removed from org.eclipse.jface_3.32.0
11:04:25.795 [ERROR] META-INF/MANIFEST.MF:0 The re-exported type org.eclipse.swt.ole.win32.OlePropertyDescription has been removed from org.eclipse.jface_3.32.0
11:04:25.795 [ERROR] META-INF/MANIFEST.MF:0 The re-exported type org.eclipse.swt.ole.win32.Variant has been removed from org.eclipse.jface_3.32.0
11:04:25.795 [ERROR] META-INF/MANIFEST.MF:5 The major version should be incremented in version 3.33.0, since API breakage occurred since version 3.32.0

[iloveeclipse]

and nobody cares.

You are too late :-)
See #1654

[jukzi]

still fails

[iloveeclipse]

still fails

Still see #1654

[BeckerWdf]

Still see #1654

#1654 is closed. So one could have the impression that all is good again.. :-(

[laeubi]

Still see #1654

#1654 is closed. So one could have the impression that all is good again.. :-(

it is all good again from the linked issue, it is just that this ticket is way to generic as it only says "fail"

Maven build succeeds

06:51:05.201 [INFO] ------------------------------------------------------------------------
06:51:05.201 [INFO] BUILD SUCCESS
06:51:05.201 [INFO] ------------------------------------------------------------------------

but build was aborted due to timeout:

Finished: ABORTED

so well.. technically it is not failing ...

[BeckerWdf]

so well.. technically it is not failing ...

Thanks @laeubi and @iloveeclipse for taking care.
But to be honest this does not really answer the question: "How should we continue with PRs currently?" I am now unsure if it's ok to merge anyway or if it's better to not merge PRs at the moment.

[laeubi]

As said if we asumme everything wil not timeout it should work, if we thing we are too close the timeout might be increased here:

eclipse.platform.ui/Jenkinsfile

Line 3 in d7676d3

timeout(time: 80, unit: 'MINUTES')

[jukzi]

"How should we continue with PRs currently?"

Do you expect green builds in PRs in the future? go #1644 and vote "Yest",

[laeubi]

"How should we continue with PRs currently?"

Do you expect green builds in PRs in the future? go #1644 and vote "Yest",

How would disable maven warnings reporting fix timeout in Jenkins or API tools failures?

SPOILER: platform.ui has not enabled any quality gates so no warning will ever "fail" the build ....

[jukzi]

The idea was to have the same settings in all repositories. maybe we should close that poll and create a new one to make it clear which repo it is about.

[laeubi]

It doesn't matter at all if any inconvenience even if it does not relate is blamed on "something else" instead to try to just take a closer look... and try to understand why and even if it will never make any difference.

Instead everyone is yelling how it could happen that an issue slipped trough to the ibuilds, but if it is detected earlier everyone jelling its unrelated to my PR ... so no matter what the complains are either here or there ... we have had two polls already, both tending to keep warnings visible so having another poll will maybe change it yes or we just have jetzt another one until it has the "right" outcome.

[BeckerWdf]

Let's have a look at the current state with the eyes of an external contributor - not a committer of the project.
Somebody finds a bug and takes the extra mile to even fix it by providing a PR. She now get's a red CI-Vote for something she did not introduce. How should she continue? What should she think about the "healthiness" of the project she just invested time into.

[akurtakov]

Let's have a look at the current state with the eyes of an external contributor - not a committer of the project. Somebody finds a bug and takes the extra mile to even fix it by providing a PR. She now get's a red CI-Vote for something she did not introduce. How should she continue? What should she think about the "healthiness" of the project she just invested time into.

That's exactly why I came to the conclusion that separate projects working against fixed tools/deps/etc. is the only way. Right now a change in apitools, a change in ecj, a change in swt, etc. could break anything anywhere on a day to day basis.

[jukzi]

It won't help if the tools then fail on the next tool update for several distinct reasons which are even harder to identify.
What might work: any tool change is tested against all repositories before accepted. i.e. for example any jdt commit would need to compile every other repo first.

[akurtakov]

on the next tool update for several distinct reasons which are even harder to identify.
What might work: any tool change is tested against all repositories before accepted. i.e.

Jenkins power the project have (JDT/PDE/Platform) has can not handle such load.

[merks]

May I asked for a reference to a specific concrete example, because I get so confused when things fail because of timeouts, because out of memory exceptions, network failures, versus all the other reasons (good or bad) why they fail. I see master is okay now, so what exactly are we discussing now?