Reference Application 2.6 will be Released on May 4th at 2 p.m. UTC.

Hello everyone the proposed date for releasing Reference Application 2.6 is May 4th at 2pm UTC.


@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, @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’.

@hilz041 & @raff, please let us know asap if you foresee any blockers to getting the release out.

@cintiadr, thanks for the info.

@burke, there’s no blockers as for now.

@cintiadr, just wanted to let you know that 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 ? 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 :slight_smile:

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 :slight_smile:

But I have no idea about thestandalone binaries, which failed on the second run as well :confused:

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]
simple	04-May-2017 13:45:54	Failing task since return code of [/usr/share/apache-maven-3.2.3/bin/mvn --batch-mode deploy:deploy-file -DgroupId=org.openmrs.distro -DartifactId=referenceapplication-package -Dversion=2.6.0 -Dpackaging=zip -Dclassifier=standalone -Dfile=target/ -DrepositoryId=openmrs-repo-releases -Durl=] 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:
build	04-May-2017 21:31:50	[INFO] Uploaded: (281466 KB at 8211.5 KB/sec)
build	04-May-2017 21:31:50	[INFO] Uploading:
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 ( -> [Help 1]

I was looking , 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 :confused:

I unshared the artefact and I could delete it :slight_smile:

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 (?):

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 :wink:

Yes, please make it so that a new RA release is deployed to the demo server automatically.

Done :slight_smile: