New Bamboo agent available for tests


(Cintia Del Rio) #1

I rebuilt one of our bamboo agents, yokobue.

It’s an upgraded OS, upgraded docker, upgraded puppet, and everything in between.

The main difference is that JDK 8 is the default java now.

If you have a build that went unexpectedly red, check if it ran on the new agent: 39%20PM

If so, and it passes in other agents, please let me know and I will investigate.


(Daniel Kayiwa) #2

Thanks @cintiadr for the good work! :slight_smile:

Will keep an eye on this and let you know when it happens.


(tendo kiiza Martyn) #3

@cintiadr thanks


(Cintia Del Rio) #4

A new agent, called ‘xindi’, is also available for tests.


(Cintia Del Rio) #5

Yue.openmrs.org was rebuilt as well.


(Cintia Del Rio) #6

The last agent, yak, was recreated.

All brand new ones :smiley:


(Daniel Kayiwa) #7

Thanks @cintiadr for rebuilding our house! :smile:


(Daniel Kayiwa) #8

@cintiadr are these CI failures in any way related to the new agents?

https://ci.openmrs.org/browse/SON-OPENMRSCOREMASTER-1867

https://ci.openmrs.org/browse/ASU-ASUML-150


(Cintia Del Rio) #9

Maybe?

I will check.


(Cintia Del Rio) #10

The sonar one I doubt.

It has been running in the new agents with green results for a long time. Maybe some security patch was applied and broke it, but it’s not really the new agents at all.


(Daniel Kayiwa) #11

Could it be a java upgrade effect as per this? Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter

Bamboo turns green when i make these commits:

This commit: https://github.com/openmrs/openmrs-module-chartsearch/commit/2c9828738669341a486bd1f904de38c245b0f1fc

This: https://github.com/openmrs/openmrs-module-appointmentschedulingui/commit/ab3046481a7aed08b1e7a515a3a4f3035b705ba0

And this: https://github.com/openmrs/openmrs-core/commit/7a6f890930fc0c3c21cda8afbf5bf5675ed64e1a

I can revert these commits, once the main cause is fixed, because they were purely for troubleshooting purposes.


Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter
(Cintia Del Rio) #12

I think it makes sense to add those commits, google searches were telling me that too.

So it makes sense they fixed it but it was already running on the new agents, but it’s not clear why they just broke now?

Your fixes are good and fine as far as I can see, no other side-effects, but I’m afraid I couldn’t find anything that could have triggered the problem in the first place.


(Daniel Kayiwa) #13

@cintiadr looks like each and every build is now failing until when we make this commit to it. Still wondering if am doing the right thing. :slight_smile:

https://ci.openmrs.org/browse/RESTWS-RESTWS-773/log


(Cintia Del Rio) #14

Let’s try to build a case here.

Previous green build was on 25 Oct 2018, 6:22:13 PM , UTC Xindi is a new machine, so it wasn’t rebuilt.

We had some patches applied, and we had a restart. -Java wasn’t upgraded-

But we have: SUREFIRE-1588

I’m not going to tell you I know what’s happening, but it appears I might be able to apply a patch that affects all builds.


(Cintia Del Rio) #15

Oh, it appears that java was indeed upgraded. on the Oct 23.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925#38 Maybe the restart was the trigger here.

Adding that line won’t hurt, and it’s probably a good thing anyway, and I really don’t want to keep that package without security updates.


(Cintia Del Rio) #16

I don’t really have any good solutions.

The ‘nicest’ one is to actually commit that line to all affected projects. Apparently the package upstream decided to do that change, so I really cannot downgrade and ignore security patches forever :confused:


(Cintia Del Rio) #17

@dkayiwa can we get away with it updating the affected pom files?


(Daniel Kayiwa) #18

@cintiadr yes we are now updating pom files for each module whose build fails.