... | ... | @@ -48,7 +48,7 @@ cd stork |
|
|
|
|
|
- Stork project is currently set up in a way that allows only fast-forward merges. This is not the only possible option, but it works well for other projects (Kea, ISC DHCP) and 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 significant CI integrated with gitlab, but this will change soon. Before merging, please run unit-tests on your own.
|
|
|
- Before merging, please run unit-tests and linters on your own (useful commands: `rake unittest_backend` and `rake lint_go fix=true`, also `rake lint_ui`)
|
|
|
|
|
|
- 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 manually:
|
|
|
```console
|
... | ... | @@ -64,7 +64,7 @@ git rebase --skip # if there are specific commits that you decided to skip, e.g. |
|
|
|
|
|
- Once you merge your changes to master, gitlab should close the merge request and the issue.
|
|
|
|
|
|
**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.
|
|
|
- Make sure the Changelog is updated.
|
|
|
|
|
|
# GIT commit logs
|
|
|
|
... | ... | @@ -80,10 +80,12 @@ If you really like to, you can squash your own commits. Nobody in the Kea team d |
|
|
|
|
|
# Changelog
|
|
|
|
|
|
Changelog entries are requires for every change that is visible by a user. This covers things like new features (they may want to start using it), bug fixes (they may be affected and a fix may be the reason to upgrade), changes to build process (they may need to install new software dependency or, even when the dependency installation is automated, they should be aware that new piece of software will appear in their system) or documentation. Changelog should be modified on a branch and then merged to master. This is the same change as everything else, and should go through the usual review process.
|
|
|
Changelog entries are required for every change that is visible by a user. This covers things like new features (they may want to start using it), bug fixes (they may be affected and a fix may be the reason to upgrade), changes to build process (they may need to install new software dependency or, even when the dependency installation is automated, they should be aware that new piece of software will appear in their system) or documentation. Changelog should be modified on a branch and then merged to master. This is the same change as everything else, and should go through the usual review process.
|
|
|
|
|
|
The Changelog entries will be used as part of the release notes. Please make sure the text is descriptive and understandable by users, who may not be experts or don't follow developers' discussions.
|
|
|
|
|
|
We previously put SHA, gitlab issue and MR numbers in, but right now we settled for putting Gitlab issue only. It's enough to get all the related data.
|
|
|
|
|
|
An example changelog entry looks like this:
|
|
|
|
|
|
```
|
... | ... | |