|
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://apps.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.
After successfully logging in to the main ECMWF website (www.ecmwf.int), you will probably find you still cannot see the OpenIFS git repository. To be granted access, please contact openifs-support@ecmwf.int. |
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.
We recommend that users login to Bitbucket via the web interface and upload their ssh public keys into the user profile to allow passwordless access to the git repositories.
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@git.ecmwf.int:7999/oifs/oifs40r1.git 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' |
The release branches mirror the versions available on the ftp site and will be fully tested. To checkout a published release use the release tags. All new code should be placed in a 'feature' branched from 'develop'. Don't create a new feature from a release branch. Only hotfixes should branch from releases (see branching model below). |
All releases are "tagged". The tags are applied to the git commit that correspond to the tarfiles made available via the OpenIFS ftp site.
Checking out a specific release is very easy, just specify the release, e.g.
% git clone ssh://git@git.ecmwf.int:7999/oifs/oifs40r1.git oifs40r1v1.1 ...... % cd oifs40r1v1.1 % git checkout v1.1 Note: checking out 'v1.1'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. |
The warning about the 'detached HEAD' state is because the tagged commit is not the most recent commit in the repository.
Hotfix branches are one reason to checkout a specific release. Hotfix branches should only be created from release branches. They should be merged into the same release branch (and merged to 'develop' if not already).
See the branching model below.
The minor release number e.g. 1.x should be incremented for minor releases after hotfix branches are applied.
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:
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.
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.
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://git.ecmwf.int/stash for more details. |
The solution is to follow this procedure
Portions of this page written by ECMWF user support: Daniel Santoalla.