Distro build failing

Distro build started to fail in https://ci.openmrs.org/browse/REFAPP-OMODDISTRO-5734 after https://ci.openmrs.org/browse/AU-AUL-138

@isears, @dkayiwa are you looking into that?

I have just seen it. Though it does not look related to that commit.

Thanks @dkayiwa and @raff. I saw the failed build and saw that it was a commit other than mind, but after a ping from Daniel I see that the failing tests are the same as the ones that my previous commits were causing problems with, so it probably has something to do with me, will look into it.

Mark

I fixed this a few hours ago, should be all set now.

1 Like

Thanks @mogoodrich!

For reference it was fixed in https://ci.openmrs.org/browse/CA-CA-2980

I wonder if there’s any clever way of reporting all recent changes, which could possibly have broken things… In our current setup a number of changes from RA dependencies can end up in the RA parent build.

@cintiadr, do you know, if Bamboo has a feature (or a plugin), which can display all children dependencies, which were built in between 2 parent builds.

A long long time ago I did create this plugin: https://ci.openmrs.org/plugins/viewBuildDepTree.action Not sure if it’s related at all to what you what.

Maybe https://marketplace.atlassian.com/plugins/com.atlassianlabs.bamboo.plugins.dependency.graph/server/overview ?

I might have to upgrade Bamboo first.

Thanks! It displays dependencies between plans, which is great, but what would help here is to display children builds (typically one, but at times 2-3 for the distro build), which were included in a particular parent build.

I know a build gets triggered by one child at a time, but it is sometimes the case that 2-3 children builds may be running at the same time and their artifacts may end up being included in the parent build. I hope I explained it better.

No, I don’t think it’s easy in Bamboo because the ‘trigger/child’ feature is such a weak link. We maybe could create such a plugin that try to discover what happened after the fact, but it wouldn’t be trivial.

We’d probably be better getting that feature out of GoCD (or maybe concourseCI), but from experience the more dependencies between pipelines you have, the harder it gets (and very very CPU expensive to calculate the graph too).