I went to release the next version of the OpenMRS SDK using bamboo and ran into some errors due to integration tests failing during the “release” phase.
Note that these tests do pass when run during the normal build, and the error appears to be due to being unable to find mvn:
|21-Apr-2021 16:52:12|[INFO] Exit code was non-zero: 127; command line and log = |
|21-Apr-2021 16:52:12|[INFO] bin/mvn -DopenMRSPath=/home/bamboo-agent/bamboo-agent/xml-data/build-dir/SDK-SDK-RTM/integration-tests/target/test-classes/integration-test -Ddistro=referenceapplication:2.2 -Ddebug=1044 -DdbDriver=mysql -DdbUser=mysql -DdbPassword=mysql -DdbUri=@DBNAME@ -DdbSql=null -DbatchAnswers=adf0e28b-8560-4588-a4c2-045de579ed18,/usr/lib/jvm/java-8-openjdk-amd64/jre,8080 -e --batch-mode -Dmaven.repo.local=/tmp/release.dx5zuPb org.apache.maven.plugins:maven-clean-plugin:clean org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:3.13.8:setup|
|21-Apr-2021 16:52:12|[INFO] /bin/sh: 1: mvn: not found|
Does anyone with more insight than me into the SDK or the release scripts have thoughts on this?
(In the meantime, I’m double-checking that these tests really do pass and then will likely manually force a release of the latest version, as we are partially blocked on needed some new functionality @mseaton has added to fetch OWA artifacts from locations other than bintray).
FWIW, we have always released the SDK from travis instead of bamboo.
I believe @mogoodrich must have gotten this working, as he released a new version. @dkayiwa , as a part of this ticket, we moved away from Travis in favor of Bamboo-based release process: https://issues.openmrs.org/browse/SDK-274, but it had never been run before now, so @mogoodrich must have run into a few configuration tweaks that were needed. Mark, anything to update?
I think I might’ve fixed this. From the log, it looks like it’s trying to run
bin/mvn or (more likely)
/bin/mvn, which seems to indicate it wasn’t picking up where Maven is installed on the build machine.
What’s different for the SDK from most of our other builds is that it uses the Maven Verifier Plugin to execute the test SDK commands. The Verifier Plugin seems to determine where the Maven executable should be based on this function. The only environment variable it takes into account is
M2_HOME, but the only environment variable we were setting was
MAVEN_HOME, so I simply adjusted the release step to set both
M2_HOME. Presumably, Travis has the
M2_HOME variable set by default.
Thanks @ibacher ! Yeah, it looks like it was issue finding mvn and figured it was some sort of environmental variable/path thing that I hoped someone else would know the answer too…
What was interesting is that the tests passed fine in the normal build, but just failed in the release build.
As a workaround, I went with a very not-best-practice solution… I just confirmed all the tests passed, then @Ignored them and committed, did the release through Bamboo, and then un-@Ignored them an re-committed.
We can test Ian’s changes during the next release, or just do another point release now to test?
I might prefer if we could do a dummy point release before I forget the parts I figured out to guess at the fix.
Cool, do you want to do it? Or I could try, but I’d just be sending you any errors I receive…
Done… seems to have worked!
Awesome, thanks again @ibacher !