Add "Maven Deploy" Task to end of "Release" Stage of Ref App modules

For those modules that have a release stage configured in Bamboo, I propose adding a “Maven Deploy” task as the last step of the process.

Reasoning: after doing the release, the module is upgraded to the next snapshot version, and the change is pushed to git, but I don’t think that snapshot version is deployed to the SNAPSHOT repo until the build runs again (ie after the next change to the module).

In the PIH build pipeline, we are automatically upgrading version numbers, and so for modules in which we are relying on SNAPSHOT version numbers, our version numbers get upgraded and then the builds fail because the snapshots don’t (yet) exist in the Maven Repo. (I’m 100% sure why our version numbers get upgraded if the versions don’t yet exist, but, regardless, building the new version as soon as we upgrade the version number seems the right think to do.)

Thoughts? Mark

Makes sense

Hum. This should be already happening for every module which belongs to the refapp. This is what is called after the release:prepare/perform ( e.g.

Do you have any occurrence of that? What happened is that apparently some modules were not released from Bamboo due to some unexpected errors (which I don’t yet have any data to investigate).

The $PREPARING_DISTRO is a Bamboo variable (!default.action | ), and the default is true. So I’d expect the SNAPSHOT to always be there just after the release if the released module is part of refapp.

Shouldn’t the git push trigger another build to be run, and thus deploy the next development snapshot?

I have always noticed what Mark reported, even when releasing from bamboo worked flawlessly. As a result i got into a habit of always manually running the bamboo plan immediately after releasing such that the snapshot for the next version gets deployed.

In fact, it doesn’t. Bamboo will ignore any commit with start with the ‘[maven-release-plugin]’, to make sure you are not building a stable version (doing a ‘mvn install’ in a non-snapshot version will cause the .m2 cache to have invalid artefacts). I do remember seen that in Bamboo code, but I’ve never tried in other CIs - but it wouldn’t surprise me if they have the same behaviour.

Daniel, even for modules which are in refapp distro? If so, something went wrong.

@cintiadr yes. For instance, i have just released version 1.2 of the adminui module. Any reference to 1.3-SNAPSHOT result into this: Failure to find org.openmrs.module:adminui-api:jar:1.3-SNAPSHOT in was cached in the local repository, resolution will not be reattempted until the update interval of openmrs-repo has elapsed or updates are forced -> [Help 1]

Until when a commit is made to the module or when i manually run its bamboo plan.

A second example is the coreapps module where i have just released version 1.11.1 and registrationapp 1.6


So, I can see you released that module in Build 135

As the preparing.refapp.distro.release was not changed, it used the default true, which committed the released 1.2 version to the distro.

The case would be different if that variable was set to ‘false’. The next snapshot would be upload to nexus, and the distro would receive the next SNAPSHOT on the commit instead of the the released version. So you wouldn’t need to add new commits to the distro like a96cd3 or 55371d.

So, automation appears to be in place, but it’s possibly not very discoverable. We are only uploading the next snapshots to nexus if the snapshot was automatically added to refapp distro by the release build in Bamboo.

  1. Should we add the SNAPSHOT to the distro as the default option?

  2. Should we always upload the snapshot, regardless if that module is in a distro or not?

1 Like

I think we should keep the default option of not adding the SNAPSHOT to the distro, but we should always upload the new snapshot, regardless if the module is in a distro or not.


1 Like

I agree. Thanks @cintiadr for looking into that!

I don’t see this documented in the Reference Application Release Process, which would explain why it wasn’t correctly set this time. :slight_smile:

@cintiadr, can you coordinate with @maurya to ensure this is added in the right place?

The change to deploy snapshots will be merged soon (PR-2), I kinda lost some git access :stuck_out_tongue: . I will merge and test it properly then :sweat_smile:

I updated Reference Application Release Process to change the preparing.refapp.distro.release bamboo variable. Feel free to reword it.

I also added two tasks in the distro release task to reset the preparing.refapp.distro.release to false after a green refapp distro release. That one is pretty hard to test, so I wouldn’t be surprised if it doesn’t work on the first time. @taremwatadeo is the new release manager, right? So please let me know if I broke it :smiley:

1 Like

Thanks a lot @cintiadr for making this happen! :smile:

About git, i have just given you admin access to the openmrs-contrib-bamboo project. I wonder how i forgot you when working on dev stages. You are now a /dev/3 :slight_smile:

Yeah, I’m not exactly a dev, so the /dev/* is sort of weird for me :wink:

@cintiadr a spill over effect of your great work to support devs. By the way, i did not know that you are a non dev. :smile: This reminds me of the fact that we need to come up with some sort of badge or grouping for non devs.