Skip to content

GitLab

Last edited by Suzanne Goldlust
Page history

BIND development workflow

BIND development workflow

Notes from the group meeting during IETF 101:

Use of public and private Gitlab repositories

Handling security incidents
  1. Mark security related issues as "confidential" in Gitlab.
  2. In your local repository, create a development branch and a test case branch. Branches whose names contain the string "security" anywhere in the name, or end with the string "-testcase", are always protected and cannot be pushed to the isc-projects/bind9 repository. After creating these branches, optionally set the upstream to the isc-private/bind9 repository.
  3. While the CVE is in progress, add protection for *_patch* branches and *_P* tags. This can be removed after public disclosure of the CVE, and ensures we will not accidentally release code prior to the planned disclosure date.
  4. Once the branches containing the fix(es) and the test case are complete, push them to isc-private/bind9 for review.
  5. Create two merge requests, one for each branch pushed in the previous step, so that they can be discussed. Make sure that the destination branch for both of these merge requests is set to main in isc-private/bind9, not isc-projects/bind9.
  6. Update the main branch in isc-projects/bind9 with a placeholder CHANGES note.
  7. When the fix has been reviewed, cherry-pick it into a separate branch for each fixed maintenance branch (*-security-*-v9_12, *-security-*-v9_11, etc.) These can only be pushed to isc-private/bind9.
  8. As the public main and v9_X branches are updated, continually rebase the private *-security-* branches.
  9. After disclosure, remove the protection on *_patch* branches and *_P* tags. Merge *-security-* branches to the relevant branches in isc-projects/bind9. Push the *_patch* branches and *_P* tags to isc-projects/bind9. Delete the *-security-* branches from isc-private/bind9.
Maintaining supported preview branches

Supported preview branches are maintained in the isc-private/bind9 repository, and are protected so they cannot be pushed to isc-projects/bind9. The branchsync script keeps them up to date by automatically cherry-picking changes from the associated v9_X branches.

Creating a merge request

Generally, issues are used for discussion of problems and merge requests are used for discussion of the specific code used to fix the problems.

While it is possible to create a merge request and a git branch from the issue page, this isn't recommended. It clutters the MR list with merge requests that have no work in them yet, and also triggers an unnecessary pipeline run. Instead, when working on a Gitlab issue, create a development branch in your local working repository. If you give the branch a name beginning with the issue number followed by a hyphen, then the branch will automatically be associated with that issue when pushed. When ready, push the branch to isc-projects/bind9, then create a merge request to go with the branch. One way to do this is to go to the pipelines page, click on the branch name, and then click "Create merge request". Edit the commit message as necessary, and check "Remove source branch when merged".

For minor changes, it isn't always necessary to create an issue in Gitlab; just create and push a branch, then create a merge request without linking to an issue.

Review labels

Several review-related labels have been added to Gitlab merge requests:

  1. Review: Set by the author when the branch is ready to be reviewed.
  2. LGTM (Merge OK): Set by the reviewer when the code is okay.
  3. Needs cleanup: Can be set by either the author or the reviewer; this indicates that regardless of the current state of the code, the branch still needs to be cleaned up -- for example, by squashing commits in git rebase -i.
  4. Author merge: The author wishes to merge this branch personally and requests that no one else click the merge button, regardless of whether it's deemed ready.
Code review

A merge request has an Assignee field and a Reviewer field. If you are assigned to one of those it will show up in "Your Merge Requests".

When you create a merge request, set the Assignee to yourself. Typically you are the one that is responsible for merging it eventually. You can change the Assignee if someone is taking over the work, but in most cases the one who created the merge request will stay the assignee.

When the merge request is ready for review, add the Review label and set the Assignee field to Unassigned. Merge requests with those attributes are ready for review.

The Reviewer field is left Unassigned. The sole purpose of this field is to request a review from a specific person. As author (or on behalf of the author) of the merge request you can set it to indicate so.

If you start reviewing a merge request, set the Assignee field to yourself. You are now the reviewer. When you are done with the review, you should assign the merge request back to the author, indicating the action item is back to the author. If you were requested to do the review in the Reviewer, make sure it is set to Unassigned when you are done reviewing the Merge request.