Section | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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.
Info |
---|
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. |
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:
Code Block | ||
---|---|---|
| ||
% 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' |
Info | ||
---|---|---|
| ||
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). |
Checking out a specific release
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.
Code Block |
---|
% git clone ssh://git@software.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.
Hotfixes
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.
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.
Gliffy Diagram | ||||
---|---|---|---|---|
|
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
Code Block |
---|
% 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.
Excerpt Include | ||||||
---|---|---|---|---|---|---|
|