Hello everyone the proposed date for releasing Reference Application 2.6 is May 4th at 2pm UTC.
2 Likes
@hilz041 we generally avoid releasing on Fridays because it is close to the weekend, just in case something in the release needs immediate attention and the concerned people are off for the weekend.
@dkayiwa, fair point. The next date Iām available to do the release is May, 2nd, but then 3rd Iām off again so May, 4th is the safest option. Iāll update the announcement.
1 Like
Thanks for the concern @dkayiwa so i think it will be cool if we pushed it to Monday. Let me edit the post to Monday
Thanks
Thanks, @hilz041 and @raff, for all the hard work & leadership!
@hilz041, could you update the road map wiki page to reflect the 4 May date in the 2.6 header?
1 Like
Just a heads up that I will not be awake/online by 2pm UTC. So, if thereās a problem when pushing the docker image to dockerhub (something you guys could not fix), I will be looking it around 9PM UTC time.
The āRelease docker imageā job should deploy 3 tags: ā2.6.0ā, ā2.6ā and ālatestā.
@cintiadr, just wanted to let you know that https://ci.openmrs.org/browse/REFAPP-OMODDISTRO-DDI-6143 failed partially (though itās not blocking the release since the 2.6.0 tag was pushed correctly to dockerhub).
Also since the release build failed I needed to deploy one prior build as the RA 2.6.0 release to the demo server. Itās technically the same so I guess itās okay to leave it as is (though someone with privileges on dockerhub could tag 2.6.0 as demo as well).
When looking at this, do you know what is the version artifact at https://ci.openmrs.org/browse/REFAPP-OMODDISTRO-RTM-6143/artifact ? Itās empty, but Bamboo says some deployment plans need it when I try to delete its definition.
Oh, silly mistake.
I fixed it and reran it. Itās run and pushed all the tags 
Oooooh, I see. So, I configured Create Bamboo deployment after releases to create a deployment version (āReference-Application-2.6.0ā) just after a maven release. The reason was even it was going to deploy the āsnapshotā image to demo (and other servers), at least it would allow you to proceed even if the release docker image push failed. Sort of a safety net for this first release.
I believe you deleted the automatically created deployment and created one from a previous build. Itās fine. I will configure this deployment to be created only after the āreleaseā docker image is pushed (and use this image instead) now that we confirmed the docker push task actually works.
If we can have the standalone task green, I can fix it in a better way
But I have no idea about thestandalone binaries, which failed on the second run as well 
build 04-May-2017 13:45:54 [INFO] Scanning for projects...
build 04-May-2017 13:45:54 [ERROR] The build could not read 1 project -> [Help 1]
build 04-May-2017 13:45:54 [ERROR]
build 04-May-2017 13:45:54 [ERROR] The project org.openmrs:referenceapplication-standalone:2.6.0-SNAPSHOT (/home/bamboo-agent-1/bamboo-agent/xml-data/build-dir/REFAPP-OMODDISTRO-PS/standalone/pom.xml) has 1 error
build 04-May-2017 13:45:54 [ERROR] 'build.plugins.plugin[org.liquibase:liquibase-maven-plugin].dependencies.dependency.version' for org.openmrs.api:openmrs-api:jar must be a valid version but is '${openmrs.version}'. @ line 496, column 17
build 04-May-2017 13:45:54 [ERROR]
build 04-May-2017 13:45:54 [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
build 04-May-2017 13:45:54 [ERROR] Re-run Maven using the -X switch to enable full debug logging.
build 04-May-2017 13:45:54 [ERROR]
build 04-May-2017 13:45:54 [ERROR] For more information about the errors and possible solutions, please read the following articles:
build 04-May-2017 13:45:54 [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
simple 04-May-2017 13:45:54 Failing task since return code of [/usr/share/apache-maven-3.2.3/bin/mvn --batch-mode -Djava.io.tmpdir=/home/bamboo-agent-1/bamboo-agent/.agent_tmp/REFAPP-OMODDISTRO-PS deploy:deploy-file -DgroupId=org.openmrs.distro -DartifactId=referenceapplication-package -Dversion=2.6.0 -Dpackaging=zip -Dclassifier=standalone -Dfile=target/referenceapplication-standalone-2.6.0.zip -DrepositoryId=openmrs-repo-releases -Durl=https://mavenrepo.openmrs.org/nexus/content/repositories/releases] was 1 while expected 0
On the second attempt, it failed to upload it jfrog (because it appears to be already there?):
build 04-May-2017 21:31:15 [INFO] --- maven-deploy-plugin:2.7:deploy-file (default-cli) @ standalone-pom ---
build 04-May-2017 21:31:16 [INFO] Uploading: https://mavenrepo.openmrs.org/nexus/content/repositories/releases/org/openmrs/distro/referenceapplication-package/2.6.0/referenceapplication-package-2.6.0-standalone.zip
build 04-May-2017 21:31:50 [INFO] Uploaded: https://mavenrepo.openmrs.org/nexus/content/repositories/releases/org/openmrs/distro/referenceapplication-package/2.6.0/referenceapplication-package-2.6.0-standalone.zip (281466 KB at 8211.5 KB/sec)
build 04-May-2017 21:31:50 [INFO] Uploading: https://mavenrepo.openmrs.org/nexus/content/repositories/releases/org/openmrs/distro/referenceapplication-package/2.6.0/referenceapplication-package-2.6.0.pom
build 04-May-2017 21:31:50 [INFO] ------------------------------------------------------------------------
build 04-May-2017 21:31:50 [INFO] BUILD FAILURE
build 04-May-2017 21:31:50 [INFO] ------------------------------------------------------------------------
build 04-May-2017 21:31:50 [INFO] Total time: 35.429 s
build 04-May-2017 21:31:50 [INFO] Finished at: 2017-05-04T21:31:50+00:00
build 04-May-2017 21:31:51 [INFO] Final Memory: 9M/205M
build 04-May-2017 21:31:51 [INFO] ------------------------------------------------------------------------
build 04-May-2017 21:31:51 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file (default-cli) on project standalone-pom: Failed to deploy artifacts: Could not find artifact org.openmrs.distro:referenceapplication-package:pom:2.6.0 in openmrs-repo-releases (https://mavenrepo.openmrs.org/nexus/content/repositories/releases) -> [Help 1]
I was looking JFrog , and the pom is there. So Iām not sure what put it in there first, or what happened. So I donāt know how to fix it
I unshared the artefact and I could delete it
Thanks @cintiadr! So after the next RA release the docker image should be automatically deployed to demo? No manual deployment needed hereā¦?
Iāve temporarily disabled the ādeploy standalone to mavenā task to make the build pass. I donāt know either how it ended up being uploaded there even though the task was failing. It is possible that the pom was deployed alone without the zip file when the build failed originally and it failed the second time trying to upload the pom, because overwriting is not allowed, but I donāt know how to find the original logs to verifyā¦
It doesnāt deploy to demo right now, but itās literally one trigger away. What it does is to create the deployment (i.e., the version you can use on a deployment environment, without extra screen to give it a name or something).
Do you want me to configure demo to be automatically deployed after a release? Itās trivial, I just thought it wasnāt something desired.
The logs are all āconcatedā when running multiple retries. If you look the logs, you will see all the several attempts (itās just hard to tell when one started and the other one finished).
I couldnāt find anything there uploading it, and looking at the time deployed it feels like pom file was part of the release (?): JFrog
Thanks @cintiadr, indeed the pom was deployed by the release step. I fixed it by setting a different artifactId for standaloneā¦ It should work now, though we wonāt find out until the next RA release in 6 months 
Yes, please make it so that a new RA release is deployed to the demo server automatically.
Done