diff options
Diffstat (limited to 'doc/development/contributing')
| -rw-r--r-- | doc/development/contributing/issue_workflow.md | 6 | ||||
| -rw-r--r-- | doc/development/contributing/merge_request_workflow.md | 5 | ||||
| -rw-r--r-- | doc/development/contributing/style_guides.md | 16 |
3 files changed, 19 insertions, 8 deletions
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md index da38d1e73b4..7029c8a8384 100644 --- a/doc/development/contributing/issue_workflow.md +++ b/doc/development/contributing/issue_workflow.md @@ -149,8 +149,8 @@ and `~"group::knowledge"` is picked up by someone in the Access group of the Pla the issue should be relabeled as `~"group::access"` while keeping the original `~"devops::create"` unchanged. -We also use stage and group labels to help quantify our [throughput](https://about.gitlab.com/handbook/engineering/management/throughput/). -Please read [Stage and Group labels in Throughput](https://about.gitlab.com/handbook/engineering/management/throughput/#stage-and-group-labels-in-throughput) for more information on how the labels are used in this context. +We also use stage and group labels to help measure our [merge request rates](https://about.gitlab.com/handbook/engineering/merge-request-rate/). +Please read [Stage and Group labels](https://about.gitlab.com/handbook/engineering/metrics/#stage-and-group-labels) for more information on how the labels are used in this context. ### Category labels @@ -181,7 +181,7 @@ For instance, the "DevOps Report" category is represented by the `devops_reports.name` value is "DevOps Reports". If a category's label doesn't respect this naming convention, it should be specified -with [the `label` attribute](https://about.gitlab.com/handbook/marketing/website/#category-attributes) +with [the `label` attribute](https://about.gitlab.com/handbook/marketing/inbound-marketing/digital-experience/website/#category-attributes) in <https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml>. ### Feature labels diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md index 166f7b350bf..9051b621bcd 100644 --- a/doc/development/contributing/merge_request_workflow.md +++ b/doc/development/contributing/merge_request_workflow.md @@ -68,10 +68,11 @@ request is as follows: 1. Use the syntax `Solves #XXX`, `Closes #XXX`, or `Refs #XXX` to mention the issue(s) your merge request addresses. Referenced issues do not [close automatically](../../user/project/issues/managing_issues.md#closing-issues-automatically). You must close them manually once the merge request is merged. + 1. The MR must include *Before* and *After* screenshots if UI changes are made. + 1. Include any steps or setup required to ensure reviewers can view the changes you've made (e.g. include any information about feature flags). 1. If you're allowed to, set a relevant milestone and [labels](issue_workflow.md). 1. UI changes should use available components from the GitLab Design System, - [Pajamas](https://design.gitlab.com/). The MR must include *Before* and - *After* screenshots. + [Pajamas](https://design.gitlab.com/). 1. If the MR changes CSS classes, please include the list of affected pages, which can be found by running `grep css-class ./app -R`. 1. If your MR touches code that executes shell commands, reads or opens files, or diff --git a/doc/development/contributing/style_guides.md b/doc/development/contributing/style_guides.md index 2a2cfebe964..444a067a780 100644 --- a/doc/development/contributing/style_guides.md +++ b/doc/development/contributing/style_guides.md @@ -56,10 +56,10 @@ The current Lefthook configuration can be found in [`lefthook.yml`](https://gitl Before you push your changes, Lefthook automatically runs the following checks: - Danger: Runs a subset of checks that `danger-review` runs on your merge requests. -- ES lint: Run `yarn eslint` checks (with the [`.eslintrc.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.eslintrc.yml) configuration) on the modified `*.{js,vue}` files. Tags: `frontend`, `style`. +- ES lint: Run `yarn run lint:eslint` checks (with the [`.eslintrc.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.eslintrc.yml) configuration) on the modified `*.{js,vue}` files. Tags: `frontend`, `style`. - HAML lint: Run `bundle exec haml-lint` checks (with the [`.haml-lint.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.haml-lint.yml) configuration) on the modified `*.html.haml` files. Tags: `view`, `haml`, `style`. - Markdown lint: Run `yarn markdownlint` checks on the modified `*.md` files. Tags: `documentation`, `style`. -- SCSS lint: Run `bundle exec scss-lint` checks (with the [`.scss-lint.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.scss-lint.yml) configuration) on the modified `*.scss{,.css}` files. Tags: `stylesheet`, `css`, `style`. +- SCSS lint: Run `yarn lint:stylelint` checks (with the [`.stylelintrc`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.stylelintrc) configuration) on the modified `*.scss{,.css}` files. Tags: `stylesheet`, `css`, `style`. - RuboCop: Run `bundle exec rubocop` checks (with the [`.rubocop.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.rubocop.yml) configuration) on the modified `*.rb` files. Tags: `backend`, `style`. - Vale: Run `vale` checks (with the [`.vale.ini`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.vale.ini) configuration) on the modified `*.md` files. Tags: `documentation`, `style`. @@ -146,7 +146,7 @@ One way to generate the initial list is to run the `todo` auto generation, with `exclude limit` set to a high number. ```shell -bundle exec rubocop --auto-gen-config --auto-gen-only-exclude --exclude-limit=10000 +bundle exec rubocop --auto-gen-config --auto-gen-only-exclude --exclude-limit=100000 ``` You can then move the list from the freshly generated `.rubocop_todo.yml` for the Cop being actively @@ -154,6 +154,16 @@ resolved and place it in the `.rubocop_manual_todo.yml`. In this scenario, do no changes to the `.rubocop_todo.yml` as an `exclude limit` that is higher than 15 will make the `.rubocop_todo.yml` hard to parse. +### Reveal existing RuboCop exceptions + +To reveal existing RuboCop exceptions in the code that have been excluded via `.rubocop_todo.yml` and +`.rubocop_manual_todo.yml`, set the environment variable `REVEAL_RUBOCOP_TODO` to `1`. + +This allows you to reveal existing RuboCop exceptions during your daily work cycle and fix them along the way. + +NOTE: +Permanent `Exclude`s should be defined in `.rubocop.yml` instead of `.rubocop_manual_todo.yml`. + ## Database migrations See the dedicated [Database Migrations Style Guide](../migration_style_guide.md). |