... | ... | @@ -4,12 +4,6 @@ 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.
|
... | ... | @@ -25,6 +19,19 @@ While it is possible to create a merge request and a git branch from the issue p |
|
|
|
|
|
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.
|
|
|
|
|
|
##### Review tags
|
|
|
##### 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".
|
|
|
|
|
|
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:
|
|
|
|
|
|
(to be completed) |
|
|
\ No newline at end of file |
|
|
1. Review: Set by the author when the branch is ready to be reviewed.
|
|
|
1. Merge OK: Set by the reviewer when the code is okay.
|
|
|
1. 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`.
|
|
|
1. 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. |
|
|
\ No newline at end of file |