... | ... | @@ -4,6 +4,12 @@ Notes from the group meeting during IETF 101: |
|
|
|
|
|
#### Use of public and private gitlab repositories
|
|
|
|
|
|
##### 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 when that issue when pushed. When ready, push the branch to isc-public, 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".
|
|
|
|
|
|
##### Handling security incidents
|
|
|
|
|
|
1. Mark security related issues as "confidential" in gitlab.
|
... | ... | @@ -17,14 +23,8 @@ Notes from the group meeting during IETF 101: |
|
|
|
|
|
##### Maintaining supported preview branches
|
|
|
|
|
|
(to be completed)
|
|
|
|
|
|
#### Review procedures
|
|
|
|
|
|
##### Creating a merge request
|
|
|
|
|
|
(to be completed)
|
|
|
Supported preview branches are maintained in the isc-private repository, and are protected so they cannot be pushed to isc-public. The branchsync script keeps them up to date by automatically cherry-picking changes from the associated v9_X branches.
|
|
|
|
|
|
##### Tags
|
|
|
##### Review tags
|
|
|
|
|
|
(to be completed) |
|
|
\ No newline at end of file |