...
There is also a help command - python scripts/rr_git.py --help
Tagging
Bamboo uses branches to build - and the recommended way is to branch on a tag. Go to the housekeeping clone you create and run
python scripts/rr_git.py --action tag --tag-label vX.X.X.--destination ~/tmp
will clone and tag all the main products and their components. We do this because they share components. It uses the requirements file to get the sub-components.
| Info |
|---|
The destination folder should be empty beforehand (in particular don't have the housekeeping folder in it) |
Branching
Run
...
Check out the Code
The following command will checkout SiteValidation, Validation, Editor and Merge into the specified folder, along with any direct requirements from their requirements.txt files.
The destination folder must exist but also MUST be empty beforehand - in particular do not checkout the housekeeping folder under it. Also do not add any other sub-folders to it yourself later.
| Note |
|---|
Before doing this you MUST have done the steps at the end of the Release page to merge and tag the previous branch otherwise the following commands will fail. |
The first command clones all the repositories - including those from the requirements.txt. The second creates a new branch based on a particular tag.
| Code Block |
|---|
rr_git.py --destination C:/MyWork/UKRR/Y.Y.Y rr_git.py --action branch --tag-label vX.X.X --branch-label |
...
Y. |
...
Y. |
...
Y --destination |
...
C:/MyWork/UKRR/Y.Y.Y |
| Note |
|---|
Git, or at least the version of Git on my PC breaks if a tag and branch exist with the same names. I am trying to prefix the tag with a 'v'. |
...
Tags should have a 'v' prefix. This is because Git seems to complain if you have a branch and tag with exactly the same name. The Tag Version vX.X.X should be the latest tag in the Master branch i.e the previous release. While I think this should be okay I think it would be more correct when doing a non-hotfix build to branch from master. I think this requires
|
| Warning |
|---|
The above commands seem to be creating the branch but not switching to it. This needs investigating but in the meantime check manually that the version branch is the current one and change if not. |
Modifying requirements.txt
...
-e git+ssh://jira.renalregistry.nhs.uk:7999/rr/utils@1utils@Y.0Y.14#eggY#egg=rr.utils
-e git+ssh://jira.renalregistry.nhs.uk:7999/rr/rr_logging@1logging@Y.0Y.14#eggY#egg=rr_logging
-e git+ssh://jira.renalregistry.nhs.uk:7999/rr/rr_common@1common@Y.0Y.14#eggY#egg=rr_common
for branch 1.0.14
In the branching step, all the components that are needed to be changed will have been cloned in the destination folder so finding the requirements.txt files to be changed will be easy.
...
There appears to be a command -
...
Where Y.Y.Y is the new version number and the name of our branch.
This can be done with the command.
| Code Block |
|---|
rr_git.py --action update --branch1 Y.1 Y.10 Y --destination~/tmp C:/Mywork/UKRR/Y.Y.Y --message "Update requirements.txt"to do the above automatically, however it doesn't work correctly - particularly if the requirements.txt already contains a branch tag |
| Note | ||||||||
|---|---|---|---|---|---|---|---|---|
At the moment the above command willl only work if there isn't an existing branch tag in the URLs in the URLs. If there is the Search/Replace will duplicate the tags and things will break. There shouldn't be any tags in the URls if the Deployment instructions have been followed correctly so you should be able to use the command.
|
Updating Version Numbers
...
The version should be kept in sync for rr_validation, rr_merge, rr_editor and rr_site_validation.
You will need to commit each repo after the file has been updated.
Adding the Version to Jira
In Jira go to the "Renal Registry" Project and click the Settings ("Cog") button in the lower left hand side.
Go to the Versions section and add a new Version entry for the new version number
Checking out already branched code (for 2nd person to work on branch)
...
| Code Block |
|---|
rr_git.py -- |
...
branch |
...
-label |
...
Y. |
...
Y. |
...
Y -- |
...
(the same command as above)
Building - Bamboo
Bamboo should be configured to create "branch" plans automatically.
If you have updated one of the sub-modules you may need to manually trigger the build job as not all dependencies are set as triggers.
Testing Releases
Builds are available here:
\\rr-bamboo.northbristol.local\Registry_Utils
Releases
First off, liaise with Fran Benoy-Deeney about any releases to be made.
Builds from the Bamboo process are available here:
\\rr-bamboo.northbristol.local\<Product>\<Branch Label>\<ISODate.BambooBuildNumber>
When the code is ready to be released,
...
destination C:/MyWork/UKRR/Y.Y.Y |
Issues
If you get the following...
| Code Block |
|---|
In rr_validation
Running git checkout v1.1.13 -b 1.1.14
Switched to a new branch '1.1.14'
Running git push -u origin 1.1.14
To ssh://bitbucket.renalregistry.nhs.uk:7999/rr/rr_validation.git
! [rejected] 1.1.14 -> 1.1.14 (non-fast-forward)
error: failed to push some refs to 'ssh://git@bitbucket.renalregistry.nhs.uk:799
9/rr/rr_validation.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details. |
And then you get...
| Code Block |
|---|
C:\Temp\UKRR\1.1.14\rr_validation>git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.
git pull <remote> <branch>
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=origin/<branch> 1.1.14 |
The solution seems to be -
| Code Block |
|---|
C:\Temp\UKRR\1.1.14\rr_validation>git branch --set-upstream-to=origin/1.1.14 1.1.14 Branch '1.1.14' set up to track remote branch '1.1.14' from 'origin'. |