Configuring Release plans from other CIs

Some OpenMRS modules are maintained by other groups, which have their own CI. It's recommended to do maven releases from CI as well.

While we encourage distributions to maintain their own bintray or other maven repository, sometimes for historical reasons a module is already deployed to our main repository.

Requirements

Confirm with the community that your modules builds belong to your CI

It's important that each module has builds in just one CI to avoid any race conditions. 

Maven repository service user

Raise a ticket to our helpdesk stating:

• Reason why you need access (to release which modules from your CI)

• Desired username

• Email to use (hopefully not a personal account, but rather a distribution list multiple people has access).

This user will be able to deploy modules and snapshots.

Github service user

Create a service account (not a personal account) in Github, and raise a helpdesk ticket:

• To add your user to the OpenMRS organisation

• To grant write access to the modules to be released using it.

Your CI slaves/Agents are in Linux

Our helper scripts are unsupported in other OS. They are tested in Ubuntu. Check master/release-prepare-perform.sh for the code.

Slaves/Agents Setup

Maven repository service user

Configure your CI agents/slaves to have the maven user credentials on its settings.xml. If you have local agents, that needs to be done in the server too. 

Github user

Create a ssh key pair for this user and add its public key to Github.

Add the private key to all the CI agents/slaves, by default path ~CI/.ssh/id_rsa. The CI user is the one running the CI processes.

If that file already exists, or you want to use another location, you can add option IdentityFile for server github.com in your ~CI/.ssh/config. Docs

Configure known_hosts

Make sure that github.com is part of the known_host files for all CI agents/slaves:

Other option is to configure StrictHostKeyChecking no for server github.com in your ~CI/.ssh/config. Docs

Repository Setup

Exactly the same as described in Changes in the Repository

Build setup

Create a manual step/task/job in your CI build for that module (check documentation for your CI tool).

This step will do the following:

• Clone your repository

• Clone openmrs-contrib-bamboo (let's say, as folder release-scripts) (*) . Make sure the build won't be triggered if this repository changes. 

• Run:

  $ export JAVA_HOME=<your java home> (e.g. ${bamboo.capability.system.jdk.openjdk-8-jdk} ) $ export MAVEN_HOME=<your maven home> (e.g. ${bamboo.capability.system.builder.mvn3.Maven 3} ) $ release-scripts/release-prepare-perform.sh -e "${git.repository.url}" -r "${maven.release.version}" [-d "${maven.development.version}"]

  • -e "${git.repository.url}" is optional if you are in Bamboo. In other CIs, make sure to configure it to the git repository URL. 

  • -r "${maven.release.version}" is mandatory, and it should follow SEMVER. This is the version that will be released. Use CI variables or any desired way to pass it. 

  • -d "${maven.development.version}" is always optional, and it's the next SNAPSHOT desired.

* Feel free to fork the original repository openmrs-contrib-bamboo and use it instead.

CI security

It's very important that your CI is secured and patched (both the software and OS), as a weakness in your CI might mean someone could deploy a malicious version of a module to our maven repository.