So there are dormant issues with our GitHub Actions builds. Some of them are actually failing and we haven’t fully realised yet because no PRs have been happening since the last successful build. I triggered two builds manually off the master branch of the Ref App and HFE modules to show examples, see here:
Some of the issues are straightforward to fix, stuff like Maven 3.8 not tolerating any sort of non https URLs anymore in configured repositories. Some issues are a lot more obscure, and there is such ones on HFE actually.
What should be do here? This is an overhead that we could have done without and it’s blocking some teams with their current PRs in progress.
This could largely be because of the use of Maven 3.8, in which case, should be temporarily point GitHub Actions to use a lower version until we figure out how to fully fix the affected projects? And if so, how can this be done?
Hey! Thanks for bringing this up. From a quick look-through, it seems there are a few different issues here that it would be good to separate:
Some builds fail because GitHub Actions is using Maven 3.8.1, but all the repository URLs are HTTP URLs. For these cases, we should just change the URLs in the POM to HTTPS. (But see below for a caveat).
Some modules (including openmrs-module-referenceapplication) rely on a version of Sass downloaded from a RubyGem repository that Maven can speak to. The repo that we are using for that is unmaintained and not available via HTTPS and there don’t seem to be any alternatives providing that service (I tried to setup our Artifactory instance, but while it can serve as a Gem repo, it doesn’t do the Gem → Maven conversion; JRuby, which is the whole reason that Maven repo for Gems existed long ago migrated to using the same code to fetch Gems as Mats Ruby) . For those modules, we’ll need to pin the build to use Maven 3.6.3, e.g., by leveraging this. The long-term solution here is probably to migrate to using the libsass-maven-plugin since the ruby-sass gem is EOL’d.
I have no idea what’s going on with the HFE failures, but I don’t think it’s Maven 3.8.1 related (or, at the very least, the same module and PR builds successfully on my machine using Java 8 and Maven 3.8.1). We can try pinning the Maven version there, but I’m not convinced that will solve things.
AFAICT, there’s no way to tell GitHub Actions “use this version of Maven for my projects”, apart from using a self-hosted runner, but that negates one of the main advantages of GitHub Actions, namely, we don’t have to maintain the build machines.
This plugin looks interesting. We actually ( and by we, I mean @bistenes ) recently updated our pihcore module to finally replace the ruby-gems sass compilation with one based on Javascript. Brandon’s work to do that can be seen here:
So that’s another approach to consider (I haven’t done a comparison of using npx vs. the libsass-maven-plugin). Perhaps @bistenes could comment. It would be great to get rid of the ruby gems across the reference application ecosystem.
Yeah, I’m not sure either. From the logs, it appears that only one test class is failing (ObsReferenceTagTest), and all 12 tests in that class are failing, so there is likely something specific just about that test class and how it is setup.
One thing we could do (not sure if it would entirely help in this instance) would be to adjust our Github actions jobs to save the contents of /home/runner/work/openmrs-module-htmlformentry/openmrs-module-htmlformentry/api-tests/target/surefire-reports as an artifact that can be viewed after the job is completed.
One other thing I’d say about Github Actions - when I last worked on them, I found them tricky because it was so hard to test locally. You had to commit to the repo as you tweaked your configurations until you got things working. It looks like now there might be better tools that would allow us to better evolve our workflows, and also to get to the bottom of issues like we are facing above. For example:
Thanks for pointing that tool out… it looks really useful for diagnosing issues with builds like this. Yeah, I’ve routinely made multiple commits just to get CI working.
Well, one strength of the npm approach is that it uses a supported version of Sass (technically libsass is also deprecated, just more recently deprecated than the Ruby Gem). The downside is that I’m not sure whether we can support the SDK’s watch mode with the NPM version.
AFAIK, the SDK / UI Framework have never been able to “watch” scss without first requiring a compilation step from scss → js. Once an scss file is compiled to js into the resources folder, then the SDK watch will pick up and deploy those changes. So the process would be the same for whatever build step we use, whether it is the libsass plugin or an npm/npx execution within the maven compile / package phase. I could be wrong, but that’s my understanding.
For the ObsReferenceTagTest, it looks like there are actually 17 tests, and only 12 are failing? So would be good to try to cross-reference what is passing and what is not and see if that provides any hints.
@mksd no, sorry, I’ve pretty much been off for the past two weeks, but back now, will try to take a look this week, at least to analyze what is failing in greater detail…
Did anyone change anything in the actions configuration in the 8 days since the HFE build ran? 
