Access to Bitbucket web interface

Access to Bitbucket requires that you can login to the main ECMWF page: http://www.ecmwf.int/. This is normally the case if you have an account on ECMWF systems. Use your normal userid and secureid password.

For users without an account, please go to https://www.ecmwf.int/registration/ and fill in the form to register for an account. Note that it will take some time for the new account to be registered on all the websites. Please wait for about an hour and then try to login to the main website https://www.ecmwf.int/ to refer the account works.

Access to git repository

To clone the OpenIFS git repository at your local site requires setting a further password to correctly authenticate with the Bitbucket server.

Make sure you can successfully log in to the main ECMWF website before following the procedure below.

Authentication

The procedure to get a password to download the OpenIFS git repository is:

• Log out from www.ecmwf.int
• Go to https://software.ecmwf.int/issues/login.jsp. Choose "Can't access your account"
• Write your user id.
• Now you should get an email from JIRA offering you a link to reset your JIRA password. Follow this link and type in the new password (it doesn't matter if you don't already have one).
• This password should be available in Bitbucket in some minutes. You can test it in Bitbucket's web interface https://software.ecmwf.int/stash/login as long as you are still logged out from www.ecmwf.int

Cloning and branching

To clone the repository at the remote site follow these steps. This will prompt for your username and the password created as described in the previous section:

% mkdir openifs
% cd openifs
% git clone ssh://git@software.ecmwf.int:7999/oifs/oifs40r1.git       # use: git clone https://nagc@software.ecmwf.int/stash/scm/oifs/oifs40r1.git external to ECMWF
Cloning into 'oifs40r1'...
remote: Counting objects: 4680, done.
remote: Compressing objects: 100% (3654/3654), done.
remote: Total 4680 (delta 1206), reused 4175 (delta 871)
Receiving objects: 100% (4680/4680), 21.45 MiB | 20.71 MiB/s, done.
Resolving deltas: 100% (1206/1206), done.
Checking connectivity... done
% cd oifs40r1
% git checkout develop                         # or whichever release version is required (the most recent is recommended)
Branch develop set up to track remote branch develop from origin.
Switched to a new branch 'develop'
% git checkout -b feature/new_idea                      # create new branch. ALWAYS branch from the develop branch, never the master branch.
Switched to a new branch 'feature/new_idea'

Branching model

OpenIFS has a small number of developers and a small number of releases. In this scenario, a single 'develop' branch with multiple release branches works well. The branching strategy is similar to the "gitflow" model but with modifications for multiple supported releases, which gitflow does not allow for.

Notes:

• All new code should branch from the main 'develop' branch as 'feature' branches e.g. feature/update-physics.
• Release branches are created from develop. From then on release branches should be fixes only, no new features. Fixes should be merged back to the main develop branch.
• Production releases should be tagged on the release branch (never the master branch, unlike the 'gitflow' model).
• Hotfixes should branch from their respective release only, and if necessary be merged into the develop branch.
• The master branch is largely redundant in this model. Only major releases, v1, v2, and not minor releases should be merged to master since v1.1 might be released after v2 which would cause difficulties merging to master.

User contributed branches

These should be organised under branches named according to the institution, and branched from 'develop'.

For example, branches from SMHI would all live under 'smih.se', such as, develop/smhi.se/long-run-changes'; from Barcelona Supercomputer Centre, 'develop/bsc.es/xios' and so on.

If necessary, these user-contributed branches can have their own 'develop' and 'release' branches before any merge takes place on the OpenIFS mainline develop branch. These are the responsibility of the site to manage.

It's desirable to follow the gitflow model under the user contributed branches to maintain consistency with the branch model.

Possible problems accessing OpenIFS git repository

git commands return error code 501; cannot clone

This is a problem with the version of git you are using.

Versions of git greater than 1.7.1 are required to work correctly with Atlassian Bitbucket software we use.  There is more information on this error provided by Atlassian but note the advice to use version 1.6 is incorrect, and versions of git greater than 1.7.1 must be used.

Getting CAPTCHA problems when trying to login at 'git clone', 'git push' or 'git pull'?

In some situations you may get an error like the following

% git pull
fatal: remote error: CAPTCHA required
Your Stash account has been marked as requiring a CAPTCHA to be solved before
you may login again. This is typically caused by too many attempts to login
with an incorrect password. The required CAPTCHA prevents your SCM client from
accessing Stash until it is solved, even if you enter your password correctly.

If you are currently logged in to Stash via a browser you may need to logout
and then log back in in order to clear the CAPTCHA.

Visit Stash at https://software.ecmwf.int/stash for more details.

The solution is to follow this procedure

• Log off the ECMWF Single Sign On system www.ecmwf.int
• Log in manually into Stash, filling the CAPTCHA field (you will be asked for it after you try a first time). https://software.ecmwf.int/stash/login
• The password is the same password you use with git, that you can change or recover in JIRA (but do allow some minutes for synchronization from JIRA to Stash

Acknowledgement

Portions of this page written by ECMWF user support: Daniel Santoalla.