Build I20231129-0600 is unstable

[iloveeclipse]

See

• https://download.eclipse.org/eclipse/downloads/drops4/I20231129-0600/
• https://download.eclipse.org/eclipse/downloads/drops4/I20231129-0600/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt
• https://download.eclipse.org/eclipse/downloads/drops4/I20231129-0600/buildlogs/comparatorlogs/artifactcomparisons.zip

Assumption is that this is caused by compiler change that might generate different bytecode now, see eclipse-jdt/eclipse.jdt.core#1631.

I'm looking into.

[iloveeclipse]

• Change on org/eclipse/ui/internal/dialogs/cpd/TreeManager$CheckListener.class is expected (and intended) & OK.
• Changes in SWT are coming from missing fragments update after [GTK] Don't use deprecated gtk_style_context_invalidate() eclipse.platform.swt#915.

[iloveeclipse]

• UI fix: Bundle version bump for 4.31 eclipse.platform.ui#1339
• SWT fix: Touch gtk fragments to fix the build eclipse.platform.swt.binaries#64

[iloveeclipse]

All PR's merged, triggered https://ci.eclipse.org/releng/job/Builds/job/I-build-4.31/10/ to see if that was it.

[iloveeclipse]

Still same SWT problems: https://download.eclipse.org/eclipse/downloads/drops4/I20231129-1000/

https://download.eclipse.org/eclipse/downloads/drops4/I20231129-1000/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt

@laeubi : is this something fragment specific?

eclipse-platform/eclipse.platform.swt.binaries#64 was supposed to force tycho rebuild the fragments.

Maven log: https://download.eclipse.org/eclipse/downloads/drops4/I20231129-1000/buildlogs/mb220_buildSdkPatch.sh.log

It looks like changes on forceQualifierUpdate.txt files in fragments (or in general?) are ignored now?

[laeubi]

It looks like changes on forceQualifierUpdate.txt files in fragments (or in general?) are ignored now?

I have no clue what is using forceQualifierUpdate.txt @mickaelistria should be the expert for baseline replace / qualifier updates.

Beside that, swt ist not build by tycho but ant.

[iloveeclipse]

I have no clue what is using forceQualifierUpdate.txt

The file is inside bundle and the change on this file should make sure the bundle is considered as changed and built.

Beside that, swt ist not build by tycho but ant.

It is built but tycho replaces it with the original version because it thinks there were no changes.
https://download.eclipse.org/eclipse/downloads/drops4/I20231129-1000/buildlogs/mb220_buildSdkPatch.sh.log

[laeubi]

Following your argumentation it is actually build by a shell script...

Please look at https://github.com/eclipse-platform/eclipse.platform.swt.binaries/blob/e2101bcac501d2ecf34cf1cbe1233569fcdfa39d/bundles/binaries-parent/pom.xml#L86 and see it calls an ant build there, the swt build itself is controlled by different environment variables and calculated build qualifiers from the outside then passed to Tycho. Anyways as said @mickaelistria is the one who knows best about forceQualifierUpdate.txt and baseline replace, maybe @akurtakov as well as he has bumped versions for SWT in the past...

[iloveeclipse]

I'm not talking about building which works fine, but about following step in maven build that replaces properly built fragment with previous version.

[akurtakov]

I think we should do just some change to java file in o.e.swt and it should be enough.

[iloveeclipse]

I think we should do just some change to java file in o.e.swt and it should be enough.

But isn't exact that happened in eclipse-platform/eclipse.platform.swt#915 ?

[akurtakov]

Only idea that comes to my mind is some kind of issue caused by natives rebuild not coming or being too late when the I-build started thus the git tags are out of sync. If this is the case this change should help it - if not we will see tomorrow but I definetely can't look into it more this evening.

[akurtakov]

Looking at https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/buildTimeTrend there hasn't been any recompile of natives today and there should have been due to change in natives.

[iloveeclipse]

Do we miss some update for the new release stream in one of the build jobs/scripts?

[akurtakov]

Do we miss some update for the new release stream in one of the build jobs/scripts?

I haven't spotted such at least.

[iloveeclipse]

But the builds simply fail:
https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/300/console

[akurtakov]

the morning is wiser than the evening

/me hopes someone figures it out while I sleep

[iloveeclipse]

But the builds simply fail: https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/300/console

See here the last steps before error:

23:16:50  [GitCheckoutListener] -> Starting recording of new commits since '1d5be83'
23:16:50  [GitCheckoutListener] -> Single parent commit found - branch is already descendant of target branch head
23:16:50  [GitCheckoutListener] -> Using head commit '434d1dd' as starting point
23:16:50  [GitCheckoutListener] -> Recorded one new commit
23:16:50  [GitCheckoutListener] -> Git commit decorator successfully obtained 'hudson.plugins.git.browser.GithubWeb@2ee9d8fc' to render commit links
[Pipeline] script
[Pipeline] {
[Pipeline] sh
23:16:51  + git log -1 --pretty=format:%ce HEAD
[Pipeline] echo
23:16:52  HEAD commit author: [email protected]
[Pipeline] error

The build should now continue with git fetching but there is some error, but which one?

Here how it should look like (from last successful build):

https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/299/consoleFull

23:02:53  [GitCheckoutListener] Found previous build 'eclipse.platform.swt/master #298' that contains recorded Git commits
23:02:53  [GitCheckoutListener] -> Starting recording of new commits since '06f3476'
23:02:53  [GitCheckoutListener] -> Single parent commit found - branch is already descendant of target branch head
23:02:53  [GitCheckoutListener] -> Using head commit '1d5be83' as starting point
23:02:53  [GitCheckoutListener] -> Recorded one new commit
23:02:53  [GitCheckoutListener] -> Git commit decorator successfully obtained 'hudson.plugins.git.browser.GithubWeb@fb2a4996' to render commit links
[Pipeline] script
[Pipeline] {
[Pipeline] sh
23:02:56  + git log -1 --pretty=format:%ce HEAD
[Pipeline] echo
23:02:56  HEAD commit author: [email protected]
[Pipeline] }
[Pipeline] // script
[Pipeline] sh
23:02:56  + git fetch --all --tags --quiet
23:03:11  + git remote set-url --push origin [email protected]:eclipse-platform/eclipse.platform.swt.git

[iloveeclipse]

https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/300/flowGraphTable/
https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/300/execution/node/20/

says

Error
Also:   org.jenkinsci.plugins.workflow.actions.ErrorAction$ErrorId: 38727473-4ebb-460e-b6dd-12ff6d5ddccd
hudson.AbortException: Abort build only triggered by automated SWT-natives update.
	at org.jenkinsci.plugins.workflow.steps.ErrorStep$Execution.run(ErrorStep.java:64)
	at org.jenkinsci.plugins.workflow.steps.ErrorStep$Execution.run(ErrorStep.java:51)
	at org.jenkinsci.plugins.workflow.steps.SynchronousStepExecution.start(SynchronousStepExecution.java:37)
	at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:322)
	at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:196)
	at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:124)
	at jdk.internal.reflect.GeneratedMethodAccessor862.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1225)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1034)
	at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:41)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
	at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:180)
	at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:23)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:163)
	at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:178)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:182)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:152)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:152)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:152)
	at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:17)
	at org.jenkinsci.plugins.workflow.cps.LoggingInvoker.methodCall(LoggingInvoker.java:105)
	at WorkflowScript.run(WorkflowScript:70)
	at ___cps.transform___(Native Method)
	at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:90)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:116)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:85)
	at jdk.internal.reflect.GeneratedMethodAccessor614.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
	at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
	at com.cloudbees.groovy.cps.Next.step(Next.java:83)
	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:152)
	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:146)
	at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:136)
	at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:275)
	at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:146)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51)
	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:187)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:423)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:331)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:295)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:97)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:139)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
	at jenkins.util.ErrorLoggingExecutorService.lambda$wrap$0(ErrorLoggingExecutorService.java:51)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:839)

[iloveeclipse]

Looks like all following builds failed at different steps with timeouts...

[iloveeclipse]

What about this: eclipse-platform/eclipse.platform.swt#919 ?

[MohananRahul]

Looking at https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/buildTimeTrend there hasn't been any recompile of natives today and there should have been due to change in natives.

Comparator in I20231129-1800 artifactcomparisons (1).zip
, not sure this was due to recompile https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/304/ overlap with Build?

[iloveeclipse]

Natives buikd was finally successful : https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/304/, we have commit here: https://github.com/eclipse-platform/eclipse.platform.swt.binaries/commits/master .

But it was finished after SDK build, so https://download.eclipse.org/eclipse/downloads/drops4/I20231129-1800/ is still broken.

I've triggered https://ci.eclipse.org/releng/job/Builds/job/I-build-4.31/12/ , that should work now.

[iloveeclipse]

https://download.eclipse.org/eclipse/downloads/drops4/I20231130-0020/ is finally OK.