Age | Commit message (Collapse) | Author |
|
Excludes MR author from gitlab_ui and single_codebase Review roulette
results.
|
|
A colon-emoji like :100: can be valid in the case where we're talking
about the GitLab feature that processes these into emojis. It's fine to
warn about those, but failing the pipeline is too restrictive.
|
|
reviewers.
|
|
|
|
So it's more modular and extensible
|
|
|
|
This would return `people.size` before, when it should return `nil`.
|
|
|
|
This commit adds a rule to Danger that warns the developer when their MR
includes changes to a CE .vue file that has a counterpart in the
EE repo or vice-versa.
|
|
Change reviewer roulette to always pick the same reviewers for the same
branch name. We do this by:
1. Making the branch name 'canonical' across CE and EE by stripping a
leading 'ce-' or 'ee-' and a trailing '-ce' or '-ee'. If people are
following our branch naming guidelines, this should give the same
branch name in both repos.
2. Converting the branch name to a stable integer by taking the integer
form of its MD5.
3. Passing that integer as a seed to Ruby's `Random` class, which 'may
be used to ensure repeatable sequences of pseudo-random numbers
between different runs of the program' (from the Ruby documentation).
The upshot is that the same branch name (in CE and EE) should always
pick the same reviewers, and those should be evenly distributed across
the set of possible reviewers due to the use of MD5.
|
|
|
|
Trainee maintainers count as reviewers, but should get more reviews than
most reviewers, as they need practice to become a maintainer. This makes
them three times as likely to be picked (compared to another reviewer;
compared to before, it's roughly twice as likely at the current numbers
for each).
Also, switch to `Array#sample` because I think it looks nicer.
|
|
|
|
|
|
This extends Danger so it informs MR authors that single codebase merge
requests need to be approved by a specific group of engineers.
Co-authored-by: Yorick Peterse <yorickpeterse@gmail.com>
|
|
|
|
Template and process improvements for documentation
See merge request gitlab-org/gitlab-ce!24315
|
|
This introduces additional method for linting,
to reduce the complexity of `lint_commits`.
|
|
|
|
# Conflicts:
# .gitlab/merge_request_templates/Documentation.md
|
|
|
|
|
|
|
|
Make danger pick reviewers and maintainers at random, for feontend,
backend, database, etc, changes, whenever files belonging to those
teams get changed.
|
|
|
|
|
|
|
|
|
|
|
|
- Also pulls URLs into vars
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Rename ~Packaging label to ~Package
|
|
Add danger check for duplicate yarn dependencies
Closes #51226
See merge request gitlab-org/gitlab-ce!21591
|
|
This danger check utilises `yarn-deduplicate` in order to show duplicate
dependencies in the yarn.lock dependency tree.
Often when introducing new dependencies or updating existing ones, yarn
does not seem to build the most optimal dependency tree.
In order to prevent those unnecessary dependency updates we are nudging
developers and maintainers to resolve these issues in MRs. Automating
this with danger especially helps, as yarn.lock files are not that easy
to review.
|
|
|
|
|
|
|
|
Namely the `ci-build` and `meta` labels.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
|
|
|
|
|
|
This adds a Danger check to produce a warning for MR titles greater than
72 characters. This is necessary because when squash on merge is used,
the MR title will be used for the commit message (at least by default).
This in turn leads to commit messages that violate our commit message
guidelines.
For more information, refer to
https://gitlab.com/gitlab-org/release/framework/issues/24.
|
|
We have a Danger check that warns if you made changes in app/ but not in
spec/. However, this only checked for changed files - not new files. If
you added an app file with no specs, it wouldn't warn; and it would warn
erroneously if you added a missing spec file while changing a file in
app/.
|
|
Danger apparently has three different objects which could contain files
you often want to check:
- git.added_files
- git.modified_files
- git.renamed_files
The problem: If a file is renamed, `modified_files` contains the file
path before the rename. In some Danger checks we use `added_files` +
`modified_files`, which might contain the deleted paths of renamed
files, but missing the new paths of renamed files.
So we need to consider `renamed_files` as well.
|
|
We disabled a lot of eslint rules on a per-file basis. This checks
touched files for those and reminds you to re-enable the rules and fix
them.
|
|
This adds a Dangerfile which executes `prettier` to find out if someone
touched Frontend files and forgot to run it on their current branch.
|
|
This changes the hard limit of 50 to a soft limit of 50, with the new
hard limit being 72 characters. This gives people a bit more space,
while still (hopefully) guiding them towards subject lines that are
roughly 50 characters long.
Fixes https://gitlab.com/gitlab-org/release/framework/issues/16
|
|
This changes our Danger integration so that it is smarter about
detecting GitLab emoji in commit messages. This is done using a two step
process:
1. We use the old regular expression to determine if a commit message
_might_ include an emoji.
2. If this regular expression matches, we then check for all existing
emoji names in the commit message. This might be a wee bit expensive,
but because we couple it with the previous step it should be rarely
executed.
This ensures we don't trigger an error when a commit message includes
text such as `:foo:bar:`, which is not a valid Emoji.
Fixes https://gitlab.com/gitlab-org/release/framework/issues/15
|
|
Relax Danger requirements about changed lines
Closes gitlab-org/release/framework#13
See merge request gitlab-org/gitlab-ce!21739
|