The merge request links on this page refer to the old (now read-only) athenaprivate1 repository. They are kept as illustrative examples.
Here we look at a handful of merge requests that implement simple changes and provide us with a good introduction to some of the common features and traits seen in merge requests you will process as a shifter.
!916 - Simple approval
The first example illustrates the main components of the merge request:
- Title and description of change
- Merge request status
- Source and target branches
- Label assignment
Please see Making a Merge Request to see how an individual merge request is created by a developer.
The progression on the merge request is shown in the discussion panel:
The first steps upon opening a merge request are usually completed by the ATLAS robot. Here an initial check is performed on which packages are affected by the changes introduced by the commit. In this case only one package is affected. If more than several packages are affected the list is truncated.
The ATLAS Robot then adds a label per domain (e.g. Tracking) which aids the filtering of merge requests for domain experts. Branch labels (main) and action status labels (review-pending-level-1) are also added. Labels form an important part of the workflow and are used to track status and to denote any issue ownership throughout the lifetime of the review.
As a shifter you will add and remove labels based on your relative role and on any decisions made during the code review. For example, if a Level 1 shifter wanted to pass inspection of the code to a Level 2 shifter they would remove the review-pending-level-1 label and add the review-pending-level-2 label using the option in the side menu of the merge request page. A full description of the merge request workflow is given in the shift guide.
In this example the review was subsequently approved by the Level 1 shifter without explicitly passing this on to Level 2 shifter. In all but trivial cases it is advisable to pass the merge request to the Level 2 shifter before the review is approved. Note that the approval label shown in the example is an advisory to merge and does not automatically trigger the merge itself. The merge still has to be performed by release coordinators or experts with the correct set of privileges.
The actual changes to the code in the merge request can be viewed in the changes panel:
!965 - Work in Progress Request
In this example the title of the merge request is prepended with WIP:. This has a special meaning in GitLab and denotes that the merge request is in a state of Work in Progress. As indicated above, once the developer is ready for any changes to be merged they just need to remove the prefix. From the point of view of the shifter the merge request does not need to be progressed until the WIP: is removed. However, feel free to put any comments in the discussion on the changes introduced in the request.
Looking at the discussion panel of this example:
You can see that the ATLAS robot has not contributed as CI build jobs are only activated once the WIP: prefix has been removed.
!947 - JIRA Issue linking
As discussed in the GitLab introduction, the Athena GitLab project favours the use of the JIRA system to track issues over the in-built GitLab issue tracker. One of the integration steps between JIRA and GitLab is push notification from GitLab to a specific JIRA issue if mentioned in a merge request title or description field.
In this example the JIRA issue ATR-16122 is listed in the title which results in a comment in the JIRA issue discussion:
!970 - Cherry picking
In earlier examples the source branch has usually been from a private fork of the Athena repository. However there are an increasing number of merge requests that are with source directories with the prefix cherry pick.In the context of ATLAS software this mostly refers to moving previously approved merges from one release branch to another (e.g. 21.1 to 21.0).
From the shifters perspective this means that the changes listed in the merge request have already been reviewed in an earlier merge request and (for the most part) does not need to be reviewed in the same manner. In this example the change is identical to merge request !954. However, be aware that the changes will affect a different branch and it is still worthwhile investigating the nature of the change to check for possible issues with the merge. Add a comment in the discussion if you feel this a not a trivial change to clarify with the developer. At the very least please ensure that the CI build job passes as expected.