| Age | Commit message (Collapse) | Author |
|---|
|
GitalyBot will try to automatically apply a milestone, and sorts the
milestones to apply based on the due date. Some milestones don't have a
due date. Notably, %Backlog doesn't have a due date.
While this might indicate a milestone isn't applied correctly on the
issues, the script should still work.
|
|
|
|
This would be a round robin way of getting a reviewer. Minimal
implementation, to see if it works.
|
|
Pavlo starts on Monday, and I'd like to prepare this change so I
don't forget.
|
|
|
|
Includes `@zj-gitlab` in the Gitaly team, and removes the Gitaly label
in favour of `devops::create` and `group::gitaly`.
|
|
|
|
If the issue this MR will close through either the commit messages or
the description have relevant labels, apply them on the MR too.
Closes https://gitlab.com/gitlab-org/gitaly/issues/1555
|
|
|
|
GitalyBot gets the issues the merge request closes and will detect the
first upcoming milestone and apply it.
This can be overridden by the user, and GitalyBot will not try again.
Another issue might be that if a MR slips, the milestone isn't updated.
|
|
Today I noticed that the labeling as applied previously aren't correct
for the throughput measurements GitLab does:
https://about.gitlab.com/handbook/engineering/management/throughput/#implementation
This change updates the labeling rules so from now on this will be
correctly applied. In the case of Gitaly performance is a feature and
not backstage as the point of Gitaly is improving performance.
En passant it fixes a small issue when no changelog entry is present.
|
|
Spotted on a MR where I was missing a MR ID, I removed a constant
which was required and used. By reintroducing the constant Danger should
work correctly again.
The docs had to link somewhere, so this change adds documentation too.
|
|
Using Danger a small rule book, @GitalyBot will apply labels and have a
few more rules on the changelog.
|
