Travis CI is a CI in the cloud, which OpenMRS started to leverage about a year or so ago for openmrs-core and now we are also using it for building and testing all reference application modules (thanks to @wyclif who configured most of them in a day or two).
The benefits of using Travis CI over Bamboo:
All build configuration is stored in a single file in a github repo. Devs can easily install dependencies and configure build agents from there. It’s less hassle as there is no need to ask the infrastructure team to configure Bamboo agents.
Integrates with external services like Saucelabs (UI tests execution), Code Climate (code quality), Coveralls (test coverage), etc.
Runs builds for pull requests.
Provides a significant pool of agents for open-source projects, which run our builds in parallel (observing less waiting for the builds to complete than on Bamboo).
I think Travis CI is also a better fit as the OpenMRS community grows. We can build and test a limited number of modules (those included in Reference Application) on Bamboo due to resource constraints. The rest of modules/projects need to have their own CI. For many setting up a Bamboo or Jenkins instance is an overkill or they cannot simply afford it.
Travis CI is free for open-source and you can basically copy configuration from any other module/owa to your own and start leveraging it.
Same applies for building and testing your own OpenMRS distribution, which we showcased here.
If others agree we could also start releasing directly from Travis CI. The project can be easily configured to create a release whenever someone commits to the special “release” branch. It can be done with a few lines here and here (note it is showcased for Bintray, but we haven’t committed to using Bintray for maven artifacts, we’ll adjust SDK to release to the correct place once it is settled).
Similar thing can be done for deploying SNAPSHOTs with every build to our maven repo.
It is also possible to trigger a build of a distribution whenever commits are made to a module. It is by running this simple script after a successful build of a module.
As you see some of the work towards relying more on Travis CI has already happened, but there’s still some left. The work, which we did so far doesn’t interfere with Bamboo and we can happily run our builds on both, however deploying SNAPSHOTs or doing releases from Travis CI means we need to stop doing that on Bamboo.
I’m posting this to hear opinions from other community members about the move.
It’s always a choice. Less infrastructure is usually better, but it usually means way less flexibility.
A few things to be aware when choosing our CI tool:
We have builds with multiple git checkouts. For example, the release jobs (main repo + scripts).
We have multiple builds per repository (e.g. transifex builds), one on commit, another ones on schedules
One snapshot deployed triggers another snapshot, up to distro refapp
We deploy to our internal infrastructure (so we need to keep secrets and keys somewhere, hopefully not manually, and not publicly accessible). We also commit from CI when orchestrating the release of refapp/distros, so it’s important to keep these creds secure but available for the build.
It’s not that we cannot do the same thing with other CIs; the difference is always how many hacks you need to do in order to keep your flow
What I mean is that: in order to migrate from one CI to another, you have to see which are the most complicated pieces we have, and see how well the new tool supports this workflow.
We have the option to change the workflow (e.g. drop snapshots builds, only do crons, so one), or to create a plan on how to do this on the new CI.
Cloud CIs are way way less flexible than on premises ones. That’s a trade off that needs to be taken into account.
For “business as usual”, Bamboo is basically working fine for us. Travis CI would give us some advantages, though I consider them as nice-to-haves.
The biggest value here would be that all modules and OWAs (regardless of whether they are community-supported, or just a personal project) and all distributions (regardless of whether they’re community-maintained, or implementation-specific) could follow the same patterns. I like that a lot.
What I don’t like is that Travis CI has no native support for dependencies between builds (and it’s not on their roadmap), or a dashboard that highlights red builds.
The lack of dependent builds is especially significant, because we have a modular system and lots of inter-module dependencies. (E.g. webservices.rest > emrapi > coreapps > registrationapp > referenceapplication is one path through the graph, but webservices.rest also triggers coreapps directly and not just via emrapi.)
Bamboo specifically has a feature where it won’t start a child build until its in-progress parent builds have completed. Having Travis blindly trigger the distro build from each individual module build is not a sufficient replacement for this. (Surely this is not a unique problem that just affects us, and someone out there has found a good solution…)
You can do git clone of the other repo as part of the Travis build.
Travis supports scheduled builds and you can use conditions to trigger different build commands based on if it was triggered by a commit or a scheduler.
You can secure keys in 2 ways. One is to encrypt them and store in the public repo. Only Travis knows how to decrypt them. The other is to put keys in a private repo and clone the repo as part of the build providing necessary credentials.
This one is the most tricky. Triggering another build is easy with a rest call, but as explained by Darius it is a bit more complicated in our case.
It can be solved with a script, which would be triggered by all modules and it would be determined from that script which repos to trigger and in what order. The script could even look at require_modules in our config.xmls. I haven’t found anything ready to use though, but it sounds like fun to implement
Since this is not top priority and our Bamboo is operational I suggest we will focus on setting up modules (which are not included in Reference Application) and OWAs with Travis CI so that one day, if needed/preferred, the switch is easy.
@ssmusoke, thanks! Which module would you like to publish that way? I’ve been intentionally delaying sharing that until we have a final decision regarding moving our maven repo (it may be by the end of November). Since you are so keen to do that let’s get your module’s snapshots deployed to the old repo for now and adjust the config once we move to a new repo. How does it sound? I can tweak your module’s config and send you a PR.
This thread is 4 years old now, but I found myself rediscovering this as I’m trying to set up some new CI processes for our Rwanda EMR modules and ensure these get built, tested, deployed automatically to Maven in a manner that is accessible and transparent to everyone involved.
Yesterday I spent some time moving our rwandareports module off of our internal PIH Bamboo server and onto Travis-CI. Thank you so much to @ssmusoke and @raff for the posted instructions, and existing modules that I could reference for this.
As you can see from the build history, it took me some fiddling to get this right, but I managed to in the end. (Note: the 401 Unauthorized Error that comes from JFrog is such an unhelpful error. They really need to improve that.) In my case yesterday, I finally tracked my issue down to the URL. Using the mavenrepo URL failed to allow deployments for me. Once I tried changing directly to the jfrog URL, deploying my snapshot builds worked. Hopefully this saves someone the hours I lost.
That aside, I’m now interested in seeing whether it makes sense to get our entire Rwanda EMR build pipeline setup using Travis, and then using this experience to determine whether we might move to Travis more broadly at PIH. As described above, Bamboo still likely has it’s place in our CI infrastructure, and won’t get replaced overnight, but I’m interested in seeing how much we can migrate over time.
Is there any active work in the OpenMRS community where this is being worked on within OpenMRS? Have we gained any further consensus on whether moving from Bamboo to Travis makes sense for us and if so, if there is any interest doing so? Obviously there is a question of resource investment and whether this is a worthwhile thing to spend scarce resources on, but it would be good to understand whether this is strategically what we would like to do, given resources.
As a follow-up to my own reply here, I also want to quickly highlight that I spent some additional time looking at the newer Github Actions capabilities, as an alternative to Travis, and found a lot of things to like there too (though like any newer solution there are still areas to improve).
I switched over our RwandaEMR module to use Github Actions for CI, including 2 jobs - one tests all PRs, and the other deploys snapshots to Maven for all commits pushed to master.
I’ll try to put together more thoughts in a separate post about our experience with this if we move ahead with it, but for now just wanted to get this out there for others particularly if they are trying to do similar things or if they have experiences to share.
