Replacing Bamboo with Travis CI

[mseaton (Mike Seaton)]

Hey @cintiadr,

Thanks so much for the detailed response. A few quick follow-ups…

@cintiadr

Hm. That sounds like something is wrong on the nexus setup. Can you please try ‘JFrog (with the slash at the end) to see if you have the same problem? I’m curious about your setup, because it’s supposed to work.

I made this commit, which resulted in failed deploy here due to 401 Unauthorized.

I changed back to the URL that uses jfrog.io, and my deployment passed.

@cintiadr

Travis is a cloud CI. It works extremely well for independent artefacts (one pipeline that doesn’t interact with others). I particularly dislike having to cut a different branch to create a release (as it breaks the whole definition of a pipeline), but it does have its purposes.

Well, now you can see above I’ve moved from Travis to Github Actions for my current experimentation

At this point, my goal is simply to set up a CI structure that will work best for a country-level distribution project, with minimal infrastructure that is owned and administered by a single organization and which is transparent and accessible for all to adopt. OpenMRS could be that if we want OpenMRS Bamboo to be used for that purpose, but it is not clear that’s what OpenMRS Bamboo is intended for, and also this seems like an opportunity to experiment with these CI tools that are more intrinsically linked to the source code.

As for any broad-scale OpenMRS migration to Travis, I’m not pushing for that…just trying to take the temperature of the room, given nearly 4 years has passed since @raff wrote up this post and he and @ssmusoke provided working examples for several modules. As you say…

@cintiadr

It’s probably not worth moving at all for now.

…that is probably true. As you detail in your blog, I think another solution would need to have clear, compelling benefits that are greater than the cost of migration, which (given our resources) is probably close to impossible at this point. But if some groups start experimenting with new approaches and find use cases for which they work quite well and are compelling, then this can be informative to the community and might provide opportunities for us to migrate opportunistically where the situation makes sense.

My guess is that there are likely at least some modules in OpenMRS Bamboo that are not part of any kind of dependency building pipeline, and only exist there to build and test upon each commit, and (maybe) to deploy snapshots and releases to Artifactory. These might be good candidates to pull out of Bamboo and into a Travis-based process, and see how that impacts things.

Speaking of Travis, I’m going to show my ignorance here, but can you clarify what you mean by your comments here?

@cintiadr

I particularly dislike having to cut a different branch to create a release (as it breaks the whole definition of a pipeline)

Thanks again for your thoughts, and no rush on responding, we are all busy!

Best, Mike