... | ... | @@ -12,45 +12,21 @@ IdentityFile ~/.ssh/id_ed25519_gitlab |
|
|
|
|
|
# Set up your git repository
|
|
|
|
|
|
Note: we previously used tomek/kea repository for expriements. That repo is now private and will be deleted in couple weeks. If there's anything of value there, please move it to the isc-projects/kea repo. Note that gitlab allows moving issues between projects. For commits, you cherry-picking or merging your changes is probably the best way to go.
|
|
|
|
|
|
To clean up existing repository do (this will abandon any changes you may have):
|
|
|
```
|
|
|
git checkout master
|
|
|
git reset --hard
|
|
|
git clean -fxd
|
|
|
git pull
|
|
|
```
|
|
|
|
|
|
To set up a new repository do:
|
|
|
```
|
|
|
git clone git@gitlab.isc.org:isc-projects/kea.git
|
|
|
cd kea
|
|
|
```
|
|
|
|
|
|
Now you can do:
|
|
|
|
|
|
```
|
|
|
# This will pull the current branch you're on from gitlab
|
|
|
git pull
|
|
|
|
|
|
# This will pull whatever you still need to salvage from trac repo
|
|
|
git fetch trac
|
|
|
```
|
|
|
|
|
|
When migrating stuff between repos, DO NOT copy files over. Use cherry-pick instead.
|
|
|
|
|
|
# Adding an issue
|
|
|
|
|
|
- If migrating from trac: If the issue is not in gitlab yet, pick a ticket in trac that you want to copy. Copy the description manually to gitlab (go to https://gitlab.isc.org/isc-projects/kea, click on issues on the left, then "New Issue"). Close the ticket in trac with a link to gitlab issue.
|
|
|
|
|
|
- If you have something new to work on, create an issue in gitlab: go to https://gitlab.isc.org/isc-projects/kea, Make sure it's assigned to kea1.5 milestone. Assign labels as necessary. Add labels if they're missing. We'll decide on the best way to substitute kea-proposed mechanism.
|
|
|
- If you have something new to work on, create an issue in gitlab: go to https://gitlab.isc.org/isc-projects/kea. Make sure it's not assigned to any project, unless you discussed this with the project manager and he is ok with adding it directly to the current milestone. We have a process to triage unassigned tickets weekly and assign them to specific milestone.
|
|
|
|
|
|
# Working on an issue
|
|
|
|
|
|
- Assign the issue to yourself. You should also assign Doing label. There are two ways of doing that. First, you can add the label manually when browsing an issue. Alternatively, you can go to https://gitlab.isc.org/isc-projects/kea/boards and move your issue to appropriate stage.
|
|
|
- Once you start working on an issue, assign the issue to yourself. You should also assign Doing label. There are two ways of doing that. First, you can add the label manually when browsing an issue. Alternatively, you can go to https://gitlab.isc.org/isc-projects/kea/boards and move your issue to appropriate stage.
|
|
|
|
|
|
- Open the issue page, e.g. https://gitlab.isc.org/isc-projects/kea/issues/3 and click create merge request. a branch will be created for you.
|
|
|
- Open the issue page, e.g. https://gitlab.isc.org/isc-projects/kea/issues/3 and click create a MR. A good trick is to click on the triangle button to get the extended create MR menu. In particular, you can use a shorter branch name. The branch name MUST start with the issue number.
|
|
|
|
|
|
- ```git pull```. Note the branch that was created will be there. Check it out and start working on the code. If you dislike the branch name being too long, consider using shorter description for the issue. However, it must still be human readable and people need to have a chance to understand what the issue is about. Also, if you have bash-completion package installed (and using bash), you can type: git checkout 3, and hit tab. The full name of the branch will be completed for you.
|
|
|
|
... | ... | @@ -62,41 +38,60 @@ When migrating stuff between repos, DO NOT copy files over. Use cherry-pick inst |
|
|
|
|
|
- as a reviewer: go to Issues->Board page. Look for an issue in review state that has no assignee. Assign to yourself. Review. Put some snarky comments. Add some more comments. Once you're done, reassign back to the developer.
|
|
|
|
|
|
- as a developer: look for issues that are assigned to you. Do your best with addressing the comments. Push your improvements to the branch. Once done reassign back to the reviewer. Do not merge until the reviewer says the code is ready.
|
|
|
- as a developer: look for issues that are assigned to you. Do your best with addressing the comments. Push your improvements to the branch. Once done reassign back to the reviewer. DO NOT MERGE until the reviewer says the code is ready.
|
|
|
|
|
|
- as a reviewer: Once all your comments are addressed, put a note that the code is ready to merge, open the MR, edit it and click on "remove WIP status". Removal of the WIP status is a clear indication the code is ready to go.
|
|
|
|
|
|
- If you can't reach an agreement after several review rounds, you can do two things: ask for a third opinion (any developer will do) or ask the manager to solve the problem.
|
|
|
|
|
|
# Merging code
|
|
|
|
|
|
- Kea project is currently set up in a way that allows only fast-forward merges. This is not the only possible option, it looks like the right way to go. It keeps the repo history much cleaner. If you complain about tons of merge conflicts, you tried to push a ticket that was too big.
|
|
|
|
|
|
- Currently we don't have any CI integrated with gitlab. Before merging, please run unit-tests as we did in the trac days.
|
|
|
- Currently we don't have any significant CI integrated with gitlab. We have shellcheck and are planning to integrate danger in gitlab CI. If any of them fail, you won't be able to merge anything. Please fix the issue before merging. Before merging, please run unit-tests on your own.
|
|
|
|
|
|
- Using rebase button on MR page is a very nice way of rebasing your branch. If there are conflicts, here's how you can rebase the code:
|
|
|
```console
|
|
|
# commit everything on your branch
|
|
|
git checkout master
|
|
|
git pull
|
|
|
git checkout <your-branch>
|
|
|
git rebase master
|
|
|
# solve conflicts
|
|
|
git rebase --continue
|
|
|
git rebase --skip # if there are specific commits that you decided to skip, e.g. because they're already on master
|
|
|
```
|
|
|
|
|
|
- Once you push your changes to master, gitlab should close the merge request and the ticket.
|
|
|
|
|
|
- Don't forget to update the commit-id in ChangeLog. Use MR (Merge Request) number, not issue number. The reason for this is that there may be multiple MRs for one issue. Also, in case we import pull requests from github, there may be no issue at all.
|
|
|
|
|
|
- Write down your thoughts. If needed, please update this page.
|
|
|
**PROCESS CHANGE**: We previously (before Oct 2019) put three things in the Changelog: Gitlab issue number, MR number and sha of the commit-id. This uniquely identified the changes, but was annoying and it was difficult to automate (in principle it could be done, but you'd have to develop a script that would use gitlab API to retrieve the MR #). After discussion with several members of the team, I propose to put only issue #. All other details are available using GL web interface.
|
|
|
|
|
|
# Notable differences compared to trac
|
|
|
# Commit logs
|
|
|
|
|
|
**Missing fields**. gitlab has fewer fields than trac. That doesn't mean it's more primitive, it just does things in a slightly different way. I (tomek) got used to it and like the new way better. Let me give you an example. Imagine a ticket that requires to update documentation about DHCPv4 parameter in Radius hook. In trac you'd have to choose which component to use: doc, radius, hook, config or dhcp4. In gitlab you can assign five labels and they'd represent what the ticket is about better than you could in trac.
|
|
|
**PROCESS CHANGE**: Previously (before Oct 2019) we were supposed to start each commit with `[#Issue number,!MR number]`. This was problematic, because you'd have to look up the MR in gitlab. Also, in cases when you're working on an experiment and you're not sure if there even will be a merge request, you may not have that number at all. As a result, the change proposal is to use `[#Issue number]`. This is something that can be fully automated with a pre-commit hook in gitlab, so you won't need to type it manually.
|
|
|
|
|
|
**Priorities**. There are priority labels after all and you can sort by them. Trac had: very high, high, medium, low and very low. In gitlab we have: critical, high, medium and low. Let's see if that's sufficient. If now, we can add very low if needed.
|
|
|
# Changelog
|
|
|
|
|
|
**Ticket and MR have separate numbers**. In trac we were used to the idea that there's one number and that number represents both the ticket and the branch name. Once the branch was merged, the ticket was closed. However, for more complex tickets we often determined that the issue is too big for one branch and we created another ticket and another branch for it. This extra work (to create additional tickets) came up from the limitation that 1 ticket = 1 branch. This is not the case in gitlab. There may be multiple MRs associated with an issue. You may think of an issue as a group ticket.
|
|
|
Changelog entries are requires for every change that is visible by a user. This covers things like new features, bug fixes, changes to build process or documentation. Changelog should be modified on a branch and then merged to master.
|
|
|
|
|
|
**No spam**.
|
|
|
An example changelog entry looks like this:
|
|
|
|
|
|
**Notifications**. Default notification level is global (i.e. you inherit the global setting which is where?). If you'd like to get everything about a project you can switch to watch in the project detail page.
|
|
|
```
|
|
|
1662. [bug] marcin
|
|
|
Prevent deadlock in the Kea DHCP servers caused by allocating
|
|
|
memory in the system signal handler. The issue was found on
|
|
|
CentOS 7.6, but could possibly affect Kea running on any other
|
|
|
OS.
|
|
|
(Gitlab #796)
|
|
|
```
|
|
|
|
|
|
**Registration for users is working**.
|
|
|
# Branch names
|
|
|
|
|
|
**We are yet to experience the power of CI**. There will be screams in the process and tears of joy at the end.
|
|
|
Branch names must start with an issue number. Yes, there has to be an issue, even if you're doing an experiment and are uncertain if the code will ever be merged. It takes 30 seconds to create one. Tomek wants to be able to dig up what you were working on when writing release notes.
|
|
|
|
|
|
# Using labels
|
|
|
One major difference,advantage or a flaw (depending on your personal preference) of gitlab is its label system.
|
|
|
|
|
|
Violet labels are for priority. There are four priority labels: critical, high, medium and low.
|
|
|
|
|
|
Orange labels are for components.
|
... | ... | @@ -110,6 +105,7 @@ Red labels are for things that should stand out. Currently there's one label: bu |
|
|
This is just a proposal. Tomek's idea was to use dark colors for important things and light colors for less important aspects. If you don't like it, we can come up with an alternative naming/coloring scheme.
|
|
|
|
|
|
# Working with multiple repositories
|
|
|
|
|
|
Here are a couple commands that may be useful during transition (trac->gitlab) period. However, they are useful if you happen to work with multiple repositories (such as processing pull request from github or working with internal repo).
|
|
|
|
|
|
To list your local branches with the tracking branches on remote repo:
|
... | ... | @@ -126,3 +122,20 @@ To set that your local branch should trac a remote branch, use: |
|
|
```
|
|
|
git branch -u remote_repo/remote_branch local_branch
|
|
|
```
|
|
|
|
|
|
## Set up alternate repositories (optional)
|
|
|
|
|
|
Very infrequently we need to access repos other than the official public one. Here's the list of optional ones, with some explanation why we could possibly need to use them.
|
|
|
|
|
|
* **trac** - We migrated to gitlab in 2018 and copied over all branches. If did some pushes to trac **after** you were supposed to do everything in trac, here's how you can still access it. ```git remote add trac ssh://tomasz@git.kea.isc.org/git/kea```
|
|
|
* **github** - We have a public clone of our repo on github. While we prefer users to send MRs on gitlab, some of thmem send PRs on github. ```git remote add github https://github.com/isc-projects/kea```
|
|
|
* **private** - When we're dealing with code changes that must not be public for a while, we use private repo. In general, it's easier to set up separate repo copy for this, but if you want to do everything on one repo, you can ```git remote add private git@gitlab.isc.org:isc-private/kea.git```
|
|
|
|
|
|
After you do this, you can:
|
|
|
|
|
|
```
|
|
|
# This will pull the changes from private repo
|
|
|
git fetch private
|
|
|
```
|
|
|
|
|
|
When migrating stuff between repos, DO NOT copy files over. Use cherry-pick instead. |
|
|
\ No newline at end of file |