Yes you need to.
Thank you @dkayiwa, I have deployed the file successfully to mavenrepo. Here is the PR for the standalone pom changes Updated CIEL version in pom.xml by abertnamanya · Pull Request #59 · openmrs/openmrs-standalone · GitHub
CC: @mherman22
1 Like
It looks like you forgot to make the version change the pom file in the master branch. Can you do it as soon as possible? Slack
Here is the PR Replaced 2.6.0-SNAPSHOT to 2.7.0-SNAPSHOT by abertnamanya · Pull Request #4213 · openmrs/openmrs-core · GitHub
1 Like
@mseaton could there be a reason why thought it best to just delete the 2.6.x branch, once the alpha is out, rather than simply fixing the snapshot version in the master branch?
@dkayiwa / @abertnamanya I was just throwing ideas out there. The 2.6.x branch seemed to have some problems - lots of commits around trying to release an alpha. I considered just committing a fix to master myself to change the pom to 2.7.0-SNAPSHOT, but I didn’t know the full history of what everyone was doing and why, so I just was trying to raise awareness. It didn’t seem like we were losing much by deleting the 2.6.x branch and recreating it again - there wasn’t anything new there as far as I could tell.
@dkayiwa now that we have the 2.6.x branch back in place, should we go ahead to the remaining steps of this alpha release which are?;-.
Once the release build turns green, release the corresponding platform branch from CI at OpenMRS Platform - OpenMRS Platform: Branches - OpenMRS Bamboo. Click on the green branch build number and run the Release stage. Override the following vatiables; “maven.release.version” variable to make sure it matches the release version of core (for example 2.3.0-alpha, 2.3.0-beta or 2.3.0), “maven.development.version” to the correct SNAPSHOT if the version being release is a prerelease (for example 2.3.0-alpha, 2.3.0-alpha.2…, 2.3.0-beta etc.), “build.release.type” to “prereleases” or “releases” depending on whether the version to release is a prerelease or full release respectively so that the released war(s) and read-me(s) are uploaded to the correct release folders on sourceforge.
Update the UAT Platform Environment: Remember to update UAT Platform server instance by running the UAT Platform Deployment plan.
as quoted from OpenMRS Platform Release Process - Documentation - OpenMRS Wiki
cc: @abertnamanya
Hi @Ivan, We are still having the same challenges with the platform release just like what was happening with the core plan OpenMRS Platform - OpenMRS Platform 2.6.x 18: Build result summary - OpenMRS Bamboo I edited the scripts for the docker to match those changes which were made to the core plan.
CC: @dkayiwa @burke @mherman22
Did you start a new build after changing that setting? You need to do a completely new build (and not just start the release job) for the change to take. (The general rule is if you change the Bamboo configuration, you need a new run in order for the new settings to take. Bamboo aggressively caches settings so that each build is reproducible).
1 Like
@abertnamanya did you delete the tags(2.5.1) at github ?
You probably want to delete the tag and release again.
Though I cannot see it here Tags · openmrs/openmrs-core · GitHub
Read the last three or four thread messages
I just run a new build which worked well. But then comes back the famous Permission denied error.
[ERROR] Failed to execute goal org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:4.5.0:build-distro (build-distro-bundled) on project platform: Unable to find/resolve artifact. Failed to read artifact descriptor for org.openmrs.web:openmrs-webapp:war:2.6.0-SNAPSHOT: Could not transfer artifact org.openmrs.web:openmrs-webapp:pom:2.6.0-20221208.215437-273: /home/bamboo-agent/.m2/repository/org/openmrs/web/openmrs-webapp/2.6.0-SNAPSHOT/openmrs-webapp-2.6.0-SNAPSHOT.pom (Permission denied) -> [Help 1]
Yes, but it wasn’t consistently applied. Basically, we had some jobs that were mounting /home/bamboo-agent/.m2 into a Docker image, basically to get access to the settings.xml file. Those mount instructions need to be changed to /home/bamboo-agent/.m2/settings.xml:/.m2/settings.xml:ro, i.e., to only mount the settings.xml file (and in read-only following @burke’s suggestion).
I’ve applied that to the builds for Core and the Platform, but there may be other relevant builds. I’ll have to manually fix the permissions on the agents before things will work, however.