New Bamboo agent available for tests

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:

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

Thanks @cintiadr for the good work! :slight_smile:

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

@cintiadr thanks

A new agent, called ‘xindi’, is also available for tests. was rebuilt as well.

The last agent, yak, was recreated.

All brand new ones :smiley:

Thanks @cintiadr for rebuilding our house! :smile:

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


I will check.

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.

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:


And this:

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

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.

@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:

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:

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.

Oh, it appears that java was indeed upgraded. on the Oct 23. 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.

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:

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

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