Branching

Whenever there is a need to branch out bahmni for a release, you can follow the below steps.

Steps to create branch

Branching should not be done on the following repositories

We should not do the branching for external dependencies. For example :

  1. Bacteriology
  2. Openmrs-module-episodes
  3. idgen services


  1. Get the latest of bahmni-scripts repo.
  2. Go to branchingScripts folder.
  3. In branch.sh, pushmaster.sh, pushbranch.sh, updateSHAs.sh scripts, add the newly created repos if any into the variable 'allrepos'.
  4. repo_revisions.properties has to be updated with commit SHA from which you want to branch for each repo. 
    It can be done by any one of the following ways:
        i)  Run the updateSHAs.sh script - this script will pick the latest commit's SHA in each branch and add it to repo_revisions.properties.
        ii)  If you do not want to branch from the latest commit,  manually update the commit sha-id for each repo and also add any new repo that has to be branched.
  5. Run branch.sh with the version-to-be-released, new version and the repo_revisions.properties file as parameters.
    (In all configs only default-config will be branched)
    Usage is given below.

    branch.sh <version-to-be-released> <new-version> <revision-properties-file>

    <version-to-be-released> is the current bahmni version which has to be released
    <new-version> is the next development version
    <revision-properties-file> is repo revision file. Provide full path of the file

    Example

    If we have to release 0.74 version, run the script with the following command.
    branch.sh 0.74 0.75 repo_revisions.properties(give full path of this file)

  6. This script will create the release branch(release-0.74) in each repo and upgrade the master branch snapshot version to new version (In our example, from 0.74-snapshot to 0.75-snapshot)
  7. Now, there will be a folder called 'allrepos' created in your home folder
  8. It contains .diff files for all repos for which the version was upgraded, verify the version if the upgrade is correctly done
  9. Now, run the pushmaster.sh, which will push the master branch (version updates)
  10. Run the pushbranch.sh and give new version name as the parameter. It will push the release branch created in each repo.
    Usage: pushbranch.sh <version-to-be-released>
    Example: pushbranch.sh 0.74 (given that 0.74 is the release branch you created)

 Emrapi needs to be released during the end of release of bahmni, create a card for it so that we don't forget to do it later.

Steps to verify all commits have been merged to higher version branches

  1. Clone the repo https://github.com/Bahmni/utilities
  2. Make sure the libgit2 package is installed (use a package manager like brew on Mac or apt-get/yum in Linux).
  3. Make sure python installed and pip is installed too (https://pip.pypa.io/en/stable/installing/).
  4. Create a Python virtualenv if you want (https://virtualenv.pypa.io/en/latest/). Its optional but reduces global python module clutter.
  5. Run the following (with sudo if not in virtualenv)
  6. pip install pygit2
  7. pip install termcolor
  8. In the utilities repo, run python branch_for_release/verify_merge.py -v1 <bahmni_version1> -v2 <bahmni_version2> -r <local_repo_path>
  9. where,
  10. <bahmni_version1> is the lower branch version to be compared eg. 0.78.
  11. <bahmni_version2> is the higher branch version to be compared eg. 0.80 or master
  12. <local_repo_path> is the file path to the repo eg ~/bahmni-code/bahmni-core.
  13. Important: Make sure the repos have the latest code pulled before running this.
  14. the -v2 parameter is optional, if not provided it will assume master.
  15. This will print out a list of possible missed commits and a list of cherry picks (which needs to be verified manually) or All Cool if all is fine.

Steps to be done in CI

Basic idea - each release will have a pipeline group(s) that is suffixed by the release version. Master branch will be tracked by the future release name (so for example, if we are currently working on 0.81 and 0.80 is released, the master will be tracked as 0.81, and release-0.80 branches will have their own pipeline group. Upon branching for 0.81 release, we will start tracking the release-0.81 branch in all repositories for 0.81 pipelines, create(or copy) a new set of pipelines for 0.82 which will track master branch).

  1. Update the pipelines meant for release to track the release branches (as they were tracking master)
  2. Create (or reuse an existing) set of pipelines for next release, name as <pipline_name>_v0_<version_number + 1> [rename an older group of pipelines is easier]
  3. The <pipline_name>_v0_<version_number + 1> pipelines should track master
  4. Edit the bahmni_version and rpm_version to the latest version in parameters of Bahmni_MRS_v0_<version_number + 1> pipeline.
  5. Edit the bahmni_version and rpm_version(if there is any) to the latest version and branch to the new git repo branch in each pipeline of the Bahmni_Pipeline_Group_Released group (Consult QA's before doing this).
  6. Check that the pipeline you are cloning belongs to any environment or not. If yes, add the newly cloned pipeline to the environment group too to make sure it gets picked up by the corresponding agents.
  7. Adjust release version number (bahmni_version) in deployment test pipelines. Check parameters of single machine install and two machine install to reflect current release status.
  8. Make sure the build for each repo is green.

Now you are done, Go for a coffee.




On this Page