|parent remote repo
upstream remote repo
|the main public ARC GitLab repo
|fork remote repo||your own GitLab remote copy of the upstream repo
|upstream||the git short-name used to point to nordugrid/arc GitLab remote repo
|origin||the git short-name used to point to your own GitLab fork remote repo
|local branch||the local copy on your computer of a branch|
|local repo||the local copy on your computer of a git remote repo|
|labels||pre-defined labels created in GitLab to help categorize issues and merge requests: https://docs.gitlab.com/ee/user/project/labels.html|
|Previous release series||Any release on previous major release series. Which at time of writing is e.g. 5.X.Y.|
|Current release series||Any release on current major release series. Which at time of writing is 6.X.Y|
|Next release series||Any release on next major release series. Which at time of writing is 7.X.Y|
Branch model overview
- the branch you will usually use as parent for your development branches
- holds all commits for any release on current major release series
- Not for backward incompatible changes
- all merged commits to master will be released at next upcoming release
- parent: master
- holds all commits relevant for current and next release series.
- is created once work with backward incompatible changes are ongoing in preparation for the next major release
- holds any development that is backward incompatible with current release series.
- is kept up to date with master by developers creating merge requests both to master and to this branch. Except for commits to master which are ONLY aimed for current release series.
- Use the label copy_mr:next when committing to master to get automatic copying of MR to the next branch
- dev-xxx branches
- parent: master
- for larger developments and/or developments needing contributions from several people
- creator of the dev-xxx branch is himself responsible of keeping it up to date with master
- direct push to the branch is allowed
There are two main ways of doing development
- Create dev branches on your fork
- Create dev-xxx branch on nordugrid/arc
Development branches on fork
To do work, the developer creates his own development branch on his fork. The work is merged into master (and next if the branch exists at the time) by issuing a merge request to the upstream repo.
Development branches on nordugrid/arc
It is accepted to create dev-branches on nordugrid/arc instead of on your fork. You would typically chose this for any of the following reasons
- You want your ongoing work to be easily visible for other developers
- You want other developers to contribute
Please name the dev branch in the following way: dev-xxx where xxx describes the work, e.g. dev-REST, dev-controldir etc.
You can push commits directly to the dev branch.
Labelling issues and merge requests
Appropriate labels must be added to your issues and merge requests. They will among other things be used to auto-create release notes.
Labels can be added and deleted at any time. Therefore, if you forget to add a label or wrongly apply a label this is easily corrected.
How to add labels
You can also use GitLab "quick-action" label keyword in the description field of the issue or merge request to add labels.
The specific labels mentioned below might not be up to date. The current available labels can always be found at https://source.coderefinery.org/nordugrid/arc/labels.
The labels come in four categories related to
- ARC component
- development type
For merge requests via the GitLab web interface.
You add the branch labels to instruct the arcbot to create additional merge requests to the branch specified in the label. If you are expecting additional commits to your merge request, you can wait with adding these labels until you are done. Remember the 'WIP' prefix in the merge request title.
The only copy_mr label in use at the moment is:
The copying of the merge request works in the following way, all done by arcbot
- A merge request is created using the same source branch, but with the specified target branch.
- The title, description and the labels are copied from the original merge request.
This label is only relevant if the next branch actually exists. It will only be created once needed, i.e. once some backward incompatible work is being prepared.
For issues or merge requests. This list might not be up to date. Check current labels from the Issues menu in GitLab.
These labels are to communicate what ARC component the development is for. All component labels have the same colour coding.
- component:none (e.g. for release-notes, or other administrative things, LICENSE changes etc)
For issues or merge requests.
These labels are to describe what type of development the work is. All type labels have the same colour coding.
The API related labels are to inform that the issue or merge request was constructed using the API via the nordugrid-arc-bot or via the python-gitlab tools
They are included by default when you use the arcbot or the gittools, and should not be used manually.
- informs that this is a merge request produced by arcbot as a result of a copy_mr:<branch> label in the original merge request
- same as above, however, the copied merge request does not include all commits from the original merge request.
- applied to original merge request to report on success/failure/warning of the merge request copying
We still use Bugzilla as before.
- Issues are not used for official bugreports
- You can for instance use issues to get feedback on suggested work
- Each non-trivial bug should have a bugzilla ticket.
- All larger changes or new features should have a bugzilla ticket.
- Bugzilla tickets are used directly in the release notes to advertise important changes.
- Please create a meaningful Bugzilla ticket title as this will be used in the release notes.
All main branches (master, next) will be write-protected, and to push changes to these one creates a merge-request.
WIP Merge Requests
You can use merge requests kind of like the issues are used, by starting the title with
WIP:. This will open a merge request and allows discussions, and continuously record commits that are pushed, but will not allow actual merging until the WIP keyword is removed.
Allow contribution from maintainers
It could be useful to enable "Allow edits from maintainers". Checking the button will give the maintainer write permissions to the source branch. It could be useful if you want to allow the maintainer to e.g. solve merge conflicts, or otherwise contribute to the source branch of the merge request.
How to create merge requests
1 Using the web-interface and arcbot to copy the merge request to the 'next' branch
If you forget to add the label that instructs the auto-creation of additional merge requests and instead add it later, the merge request will be duplicated at that point.
Any merge conflicts occurring in the original merge request, or the duplicated merge requests should be solved by developer.
To enable arcbot you must add the arcbot as a member to your fork project
- Go to
- Type "arcbot" in search field.
- Give arcbot "Master" role permission.
- Click "Add to project"
- Everything in master will be released at time of release
- A tag is made on master branch - this is the release
- Release numbering follows as before, however, we do not any more distinguish between bugfix and minor release, therefore the last digit will always be 0. A minor/bugfix has increase in the second last digit, a major release an increase in the first digit. 6.0.0->6.1.0 is a bugfix or minor release, 6.1.0-7.0.0 a major release and so on.
- The release is either a bugfix or a minor release depending on the content at time of release. There is no explicit control any more of whether next release is a bugfix or a minor release.
- If one needs to patch a release instead of creating a new release, a branch will be made from the relevant tag, and patch applied there. We have not usually done this earlier, but the possibility is here. The third digit in the release number will be used to mark the patch release.
- In need of an emergency release the third digit will be used.
- Link each merge request to any relevant and existing bugzilla ticket by adding (Fixes BUGZ-xxxx) in the title Notice the '(' ')'.
- Use labels for merge requests, to tell what components the MR relates to (core, client etc), and what type of change it is (fix, feature, enhancement etc).
- The templates available for the merge requests instruct you how to do labeling and issue or bugzilla-linking.
A webhook is set up to notify a custom web service each time a merge request is created or edited. The web service checks for labels of type
copy_mrlabel will create a copy of the original merge request but now with target
The resulting merge-requests will be created with labels
arcbot-copied-warning:<branch> if some of the cherrypicking failed. The original merge request and original author is automatically added in the first line of the description. Otherwise the merge request is a duplicate of the original, except for target branch naturally.
Merge Request template
Please use the MergeRequest template. It includes instructions on how to fill out the merge request.
Releases are git tags on the master branch.
Release notes will be created automatically by using the merge requests, their linked bugzilla tickets and the labels attached to each.
It is therefore important to