RR_Git Script

Owned by George Swinnerton
Last updated: Nov 07, 2019
3 min read

Introduction

The script rr_git.py is found in the housekeeping repository which also contains the scripts used in the Bamboo build jobs.

The purpose of the script is to support the development of the UKRR tools - Validation/Site Validation/Editor/RR Merge. Each Application is built from packages held in multiple repositories so the script handles the checking out, branching, committing etc. of these multiple repositories at once via single commands. It also retrieves metadata from the requirements.txt files about which repositories are required by each tool. Without further modification the script is not applicable to any other development tasks.

Unfortunately limited documentation was produced at the time the script was written and there appear to be some errors/omissions (although some of these may be due to trying to use the script in ways other than it was intended). The purpose of this page is to document what the code does in response to each of the commands. The pages that describe the Validation development/release process will document which commands should be used in which situation.

Destination Parameter

If --destination is supplied then it must be a valid path, otherwise the script will exit. If --destination is not supplied a folder will be created in the Temp directory.

NoClone Parameter

If NoClone is False (Default is False if not supplied) -

If --repo [SiteValidation/Validation/Editor/Merge] is supplied then that single repo is cloned. If it is omitted then all four are cloned.

The code here could be simplified as the clone statments are duplicated in each scenario of whether the parameter was supplied. Also, parameter is called "repo" however this is later used int he code to refer to the Git URL with "label" being used to refer to the name of the application.

It then does a listdir of the folder into which the 1 or more repos have been cloned. For each folder it looks in the requirements.txt files for lines which start with "-e" but aren't "-e ." i.e.

-e git+ssh://jira.renalregistry.nhs.uk:7999/rr/utils@1.1.11#egg=rr.utils

It then forms a unique list of these.

This assumes that all the custom code we use is a requirement of the top level applications. This may coincidentally be the case now but if things were structured differently you could find that Validation requires A which in turn requires B. In this scenario B wouldn't be being cloned as it's not a direct requirement.

Each branch is then cloned.

The code uses a regex to extract the repo name from the line in the requirements.txt file. This is then concatenated with the default repo base path from the script. This means that all repos must a) Be on the same server and b) be nested within the same project in Bitbucket.

All the cloning is done with the command:

git branch REPO_URL

unless the parameter --branch has been supplied in which case it uses:

git branch REPO_URL -b BRANCH

Action Parameter

--action tag

Requires

  • --tag_label v1.1.1

Function

Runs:

  • git tag v1.1.1
  • git push origin v1.1.1

--action branch

Requires

  • --tag_label v1.1.1
  • --branch_label 1.1.1

Function

Runs:

  • git checkout v1.1.1 -b 1.1.1
  • git push -u origin 1.1.1

--action delete_tag

Requires

  • --tag_label v1.1.1

Function

Runs:

  • git tag v1.1.1
  • git push origin :refs/tags/v1.1.1

GS: I'm not sure why this is trying to create the tag before it tries to delete it.

See https://stackoverflow.com/questions/5480258/how-to-delete-a-remote-tag for more information.

-- action report

Requires

  • --start_tag v1.1.0
  • --end_tag v1.1.1

Function

Runs:

  • git log v1.1.0..v1.1.1

This appears to be to list all the comits that occured between two tags.

--action update

Requires

  • --message "This is a message"

I'm not sure if this is intended to work without the branch_label parameter however I suspect with the code as-is it will crash without it.

Function

This is intended to re-write the requirements.txt in each of the cloned folders under the destination folder so that they're using the appropriate branch.

This doesn't work at the moment if the requirements.txt already contains an existing branch. It seems to assume that those have been checked out reference the master branch.

Runs:

  • git add .
  • git commit -m "This is a message"
  • git push

--action tagbranch

Requires

  • --tag_label v.1.1.1
  • --branch_label 1.1.1

Function

Runs:

  • git tag v1.1.1 1.1.1
  • git push origin v1.1.1


There is a trailing

run_action(destination, tandb.run_git_cmd)

At the bottom of the branching where it checks for the value of the action parameter, and after where the script quits when no action is specified.

I'm not sure this is required and, if it is I think it needs moving into each/any of the branches that require it than have it here, even if it does cause a small amount of duplication. I think there is a risk it'll be overlooked with unexpected consequences otherwise.