At the moment CI builds are only triggered on platform pull requests.
There maybe a cpu resource limitation, however is it a good idea to extend this capability so pull requests on modules also trigger CI builds?
We should be using travis for this – why tax Bamboo resources…We have 4 Bamboo agents that can run at once. That doesn’t seem feasible to me. Travis is configured for most of our projects…let’s use that.
@dkayiwa, I am referring to when you open a pull request on github. With platform it indicates that tests are running nd does a build and reports whether the pull request passes. This does not happen on any of the modules to my knowledge. If a CI build is triggered for the module then it is not apparent in github like for platform.
I don’t think Bamboo can handle that… nor should it – we have limited resources… Travis can be used for that as they have the resources to handle it.
While we are on the subject – make sure you clean up after yourself when you create docker containers in your Bamboo builds.
Do sudo: false – this will force it to run on their docker infrastructure.
Good timing! We’ve just started a sprint to improve our QA processes.
Please see the dashboard at https://issues.openmrs.org/secure/RapidBoard.jspa?rapidView=97&view=detail&selectedIssue=RA-1180&sprint=113
As part of the sprint we plan to enable travis-ci for Ref App modules. We’ll start from metadatasharing. See https://issues.openmrs.org/browse/RA-1180
Next we’ll enable releases of maven artifacts and omods to Bintray, https://issues.openmrs.org/browse/SDK-153
We’ll be also fixing UI tests for Ref App and making it easier for other distributions to use them by copying our setup.
Let’s join the efforts!
@raff awesome and just in time. Will the module snapshots be deployed to Nexus and possibly bin tray?
@dkayiwa, I will spend some time on this. @raff I will use the sprint and will probably need some help from you. @r0bby, I hope you can also provide some guidance when needed.
Bamboo doesn’t work well with pull requests on different forks (e.g., when it’s a branch in a different repository). I believe there used to be a plugin for that, but I’m not sure if it’s supported by now or not.
Anyway, @r0bby has a good point as well.
@raff that is awesome! 
Fixing the ui tests for the ref app is sweet! I was getting sick and tired of their random failures!
@dkayiwa, the recent failure was due to the server running low on disk space.
We can and should move away from the need for bamboo at all. We need to ask ourselves whether or not we actually, really need Bamboo or can Travis CI suffice? That would free up 3 servers (2 bamboo agents each on 2 servers PLUS the server that runs Bamboo itself).
@ssmusoke, we do plan to deploy SNAPSHOTs to Bintray at some point (actually oss.jfrog.org which is integrated with Bintray). In the scope of this sprint is publishing releases.
@r0bby, just to clarify the goal of the sprint is not to migrate away from Bamboo to Travis CI.
Personally, I do think it’s handy (but not strictly necessary) to have our own CI as the source of truth. We can definitely move some of the load from Bamboo to Travis CI. I will leave your question open.
I’m aware =)
It’s definitely something we should consider.