Thanks @dkayiwa and @raff. I’ve seen this idea above to be easier to implement as making changes to some Bahmbo Plan branche’s stages/jobs tends to actually lead you to making changes on the Master Plan. I’ve applied this approach on the Event Module Plans.
I probably gave a bad example, but there are plenty of places where this is an issue. For example: Registration App module - Registration App module: Plan summary - OpenMRS Bamboo
Indeed @mseaton. Such should/will be carefully reconfigured.
I wanted to review your work, but the 3.x build doesn’t seem to be running in Docker yet. Please let me know once you have a draft build that we can look at and provide feedback.
@raff, I’ve added a Latest Bamboo plan to each of the Legacy UI, Calculation, and Event projects. The existing plans have been renamed to indicate the specific branches they track. For example, the Event Module 3.x plan now monitors the 3.x GitHub branch, while the new Latest plan monitors the master branch. I guess I should have used Master instead of Latest.
That said, I’ll continue to clone one of the above plans as a starting point for configuring other upgraded modules that are now using Java 21. However, both the Legacy UI and Calculation Module still exhibit reproducible failures with Java 21 outside the Bamboo environment, so I’ll need to investigate those issues further.
Newly created plans so far:
@ruhanga did you see this message in the log about the environment that you are running? Note that Mockito's inline mock maker is not supported on Android.
Yes, I noticed this as well both in the CI logs and during local runs, @dkayiwa. It happens when using the Amazon Corretto–based image in our current Dev Docker setup. This issue is likely due to limited support for Mockito’s inline mock maker in that JVM environment. We could potentially resolve it by either adding an additional dependency to the Legacy UI module or upgrading our Dev Docker image to use a JVM that better supports inline mocking.
Merged with thanks @ruhanga 
2 Likes
Hi @wikumc, @dkayiwa, here’s the current list of modules configured to run with Java 21 on Bamboo CI:
- Legacy UI Module
- UI Framework Module
- Event Module
- Address Hierarchy Module
- Calculation Module
- UI Commons Module
- HTML Widgets Module
- UI Library Module
To configure additional projects to run on Java 21, follow these steps:
- Rename the existing project plan to reflect the GitHub branch being tracked, e.g., X Module 2.x.
- Clone one of the Java 21-enabled plans above and update the plan name, e.g., X Module Latest.
- Save the cloned plan, disable its initial build, and update the following:
- Repositories > Git > Repository URL
- Any relevant Variables, based on the existing module’s reference plan (e.g., X Module 2.x that was renamed in 1).
I’m happy to help configure any additional modules not listed above—please let me know!
Was this just a mere change to bamboo configurations? If yes, what do you think of using Bamboo Specs like we already do for openmrs-core? openmrs-core/bamboo-specs at master · openmrs/openmrs-core · GitHub
Modules currently aren’t set up with Bamboo Spec files, so I hadn’t considered introducing them for modules. I’m not opposed to the idea, but I still find it more straightforward to configure Bamboo projects directly within the Bamboo UI, as opposed to additionally exporting the generated configuration into the repo once everything is working as expected in the CI environment. Would be great if those configs were re-usable on other, perhaps different CI environments like GitHub Actions and, across different projects, besides versioning them.
1 Like
Among the reasons for migrating openmrs-core to Bamboo Specs was ability to easily track configuration changes. For instance, it is very easy to look at the GitHub commit history to see what you actually changed, in addition to the ability to even review proposed changes in form of pull requests. I believe this gets us even closer to GitHub actions, if the time comes for us to eventually move.
1 Like
Got it — thanks for the clarification, @dkayiwa. That makes total sense. For most modules (with a few exceptions), we’ll likely need a way to reuse the Bamboo configuration (which is not straight forward with YAML Specs). Otherwise, the simpler option would/will be to duplicate it across the various upgraded module repos.
Let us start with creating the module Bamboo Specs. Then later on we can look for clever ways of reusing them.
1 Like
Alright, on it. Do we also want to run Bamboo builds against all versions of Java, all the way from the last supported version (may be Java 8 or later) for all upgraded modules if possible?
Are you able to pull it off like we have been doing with github actions? openmrs-module-legacyui/.github/workflows/maven.yml at master · openmrs/openmrs-module-legacyui · GitHub
Yes! I’ll add support for all supported versions. Thanks.