diff options
| author | Fabio Papa <fabtheman@gmail.com> | 2019-07-12 10:37:24 -0700 |
|---|---|---|
| committer | Fabio Papa <fabtheman@gmail.com> | 2019-07-12 10:37:24 -0700 |
| commit | 6c51aadf35c4e7899da99c85c3fc4c01484819f2 (patch) | |
| tree | c683e3d7ebcf3e188f1dd85b8701ff972e7f8a3d /doc/development | |
| parent | 9b176c65159e4186f79eae2107af80e69132ba09 (diff) | |
| parent | 6457d5edb7d66df5dd3d5ba1f1ea0c56a59287a8 (diff) | |
| download | gitlab-ce-6c51aadf35c4e7899da99c85c3fc4c01484819f2.tar.gz | |
Merge branch 'maintainers-can-create-subgroup' of https://gitlab.com/fapapa/gitlab-ce into maintainers-can-create-subgroup
Diffstat (limited to 'doc/development')
66 files changed, 508 insertions, 458 deletions
diff --git a/doc/development/README.md b/doc/development/README.md index 1566173992a..a74770ae383 100644 --- a/doc/development/README.md +++ b/doc/development/README.md @@ -22,7 +22,7 @@ description: 'Learn how to contribute to GitLab.' - [Security process for developers](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#security-releases-critical-non-critical-as-a-developer) - [Requesting access to Chatops on GitLab.com](chatops_on_gitlabcom.md#requesting-access) (for GitLabbers) -## UX and frontend guides +## UX and Frontend guides - [GitLab Design System](https://design.gitlab.com/) for building GitLab with existing CSS styles and elements - [Frontend guidelines](fe_guide/index.md) diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md index c83a0427c98..7569ccc04c1 100644 --- a/doc/development/api_graphql_styleguide.md +++ b/doc/development/api_graphql_styleguide.md @@ -424,12 +424,8 @@ Will generate a field called `mergeRequestSetWip` that ### Authorizing resources -To authorize resources inside a mutation, we can include the -`Gitlab::Graphql::Authorize::AuthorizeResource` concern in the -mutation. - -This allows us to provide the required abilities on the mutation like -this: +To authorize resources inside a mutation, we first provide the required + abilities on the mutation like this: ```ruby module Mutations diff --git a/doc/development/api_styleguide.md b/doc/development/api_styleguide.md index 4fc38a460f8..0866d3baeeb 100644 --- a/doc/development/api_styleguide.md +++ b/doc/development/api_styleguide.md @@ -53,7 +53,7 @@ allowed. ### Exclude params from parent namespaces! -> By default `declared(params) `includes parameters that were defined in all +> By default `declared(params)`includes parameters that were defined in all parent namespaces. – <https://github.com/ruby-grape/grape#include-parent-namespaces> diff --git a/doc/development/architecture.md b/doc/development/architecture.md index 8319603fea2..b645a72567c 100644 --- a/doc/development/architecture.md +++ b/doc/development/architecture.md @@ -484,9 +484,11 @@ When making a request to an HTTP Endpoint (think `/users/sign_in`) the request w Below we describe the different pathing that HTTP vs. SSH Git requests will take. There is some overlap with the Web Request Cycle but also some differences. ### Web Request (80/443) + TODO ### SSH Request (22) + TODO ## System Layout @@ -505,7 +507,9 @@ To summarize here's the [directory structure of the `git` user home directory](. ### Processes - ps aux | grep '^git' +```sh +ps aux | grep '^git' +``` GitLab has several components to operate. As a system user (i.e. any user that is not the `git` user) it requires a persistent database (MySQL/PostreSQL) and redis database. It also uses Apache httpd or Nginx to proxypass Unicorn. As the `git` user it starts Sidekiq and Unicorn (a simple ruby HTTP server running on port `8080` by default). Under the GitLab user there are normally 4 processes: `unicorn_rails master` (1 process), `unicorn_rails worker` (2 processes), `sidekiq` (1 process). diff --git a/doc/development/changelog.md b/doc/development/changelog.md index 33c1c3bd9e4..bd07a01e782 100644 --- a/doc/development/changelog.md +++ b/doc/development/changelog.md @@ -35,7 +35,7 @@ the `author` field. GitLab team members **should not**. - Any user-facing change **should** have a changelog entry. Example: "GitLab now uses system fonts for all text." -- Any change behind a feature flag **should not** have a changelog entry. The entry should be added [in the merge request removing the feature flags](https://docs.gitlab.com/ee/development/feature_flags.html#developing-with-feature-flags). +- Any change behind a feature flag **should not** have a changelog entry. The entry should be added [in the merge request removing the feature flags](feature_flags/development.md). - A fix for a regression introduced and then fixed in the same release (i.e., fixing a bug introduced during a monthly release candidate) **should not** have a changelog entry. @@ -129,6 +129,7 @@ merge_request: author: type: ``` + If you're working on the GitLab EE repository, the entry will be added to `ee/changelogs/unreleased/` instead. @@ -144,7 +145,7 @@ If you're working on the GitLab EE repository, the entry will be added to | [`--type`](#--type-or--t) | `-t` | The category of the change, valid options are: `added`, `fixed`, `changed`, `deprecated`, `removed`, `security`, `performance`, `other` | | `--help` | `-h` | Print help message | -##### `--amend` +#### `--amend` You can pass the **`--amend`** argument to automatically stage the generated file and amend it to the previous commit. @@ -166,7 +167,7 @@ author: type: ``` -##### `--force` or `-f` +#### `--force` or `-f` Use **`--force`** or **`-f`** to overwrite an existing changelog entry if it already exists. @@ -184,7 +185,7 @@ author: type: ``` -##### `--merge-request` or `-m` +#### `--merge-request` or `-m` Use the **`--merge-request`** or **`-m`** argument to provide the `merge_request` value: @@ -199,7 +200,7 @@ author: type: ``` -##### `--dry-run` or `-n` +#### `--dry-run` or `-n` Use the **`--dry-run`** or **`-n`** argument to prevent actually writing or committing anything: @@ -216,7 +217,7 @@ type: $ ls changelogs/unreleased/ ``` -##### `--git-username` or `-u` +#### `--git-username` or `-u` Use the **`--git-username`** or **`-u`** argument to automatically fill in the `author` value with your configured Git `user.name` value: @@ -234,7 +235,7 @@ author: Jane Doe type: ``` -##### `--type` or `-t` +#### `--type` or `-t` Use the **`--type`** or **`-t`** argument to provide the `type` value: diff --git a/doc/development/chaos_endpoints.md b/doc/development/chaos_endpoints.md index 403a5b21827..b3406275937 100644 --- a/doc/development/chaos_endpoints.md +++ b/doc/development/chaos_endpoints.md @@ -15,23 +15,19 @@ Currently, there are four endpoints for simulating the following conditions: ## Enabling chaos endpoints -For obvious reasons, these endpoints are not enabled by default. They can be enabled by setting the `GITLAB_ENABLE_CHAOS_ENDPOINTS` environment variable to `1`. - -For example, if you're using the [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit) this can be done with the following command: - -```bash -GITLAB_ENABLE_CHAOS_ENDPOINTS=1 gdk run -``` - -## Securing the chaos endpoints +For obvious reasons, these endpoints are not enabled by default on `production`. +They are enabled by default on **development** environments. DANGER: **Danger:** -It is highly recommended that you secure access to the chaos endpoints using a secret token. This is recommended when enabling these endpoints locally and essential when running in a staging or other shared environment. You should not enable them in production unless you absolutely know what you're doing. +It is required that you secure access to the chaos endpoints using a secret token. +You should not enable them in production unless you absolutely know what you're doing. -A secret token can be set through the `GITLAB_CHAOS_SECRET` environment variable. For example, when using the [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit) this can be done with the following command: +A secret token can be set through the `GITLAB_CHAOS_SECRET` environment variable. +For example, when using the [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit) +this can be done with the following command: ```bash -GITLAB_ENABLE_CHAOS_ENDPOINTS=1 GITLAB_CHAOS_SECRET=secret gdk run +GITLAB_CHAOS_SECRET=secret gdk run ``` Replace `secret` with your own secret token. @@ -56,10 +52,11 @@ GET /-/chaos/leakmem?memory_mb=1024&duration_s=50 | Attribute | Type | Required | Description | | ------------ | ------- | -------- | ---------------------------------------------------------------------------------- | | `memory_mb` | integer | no | How much memory, in MB, should be leaked. Defaults to 100MB. | -| `duration_s` | integer | no | Minimum duration, in seconds, that the memory should be retained. Defaults to 30s. | +| `duration_s` | integer | no | Minimum duration_s, in seconds, that the memory should be retained. Defaults to 30s. | ```bash curl http://localhost:3000/-/chaos/leakmem?memory_mb=1024&duration_s=10 --header 'X-Chaos-Secret: secret' +curl http://localhost:3000/-/chaos/leakmem?memory_mb=1024&duration_s=10&token=secret ``` ## CPU spin @@ -70,23 +67,47 @@ Depending on your rack server setup, your request may timeout after a predermine If you're using Unicorn, this is done by killing the worker process. ``` -GET /-/chaos/cpuspin -GET /-/chaos/cpuspin?duration_s=50 +GET /-/chaos/cpu_spin +GET /-/chaos/cpu_spin?duration_s=50 +``` + +| Attribute | Type | Required | Description | +| ------------ | ------- | -------- | --------------------------------------------------------------------- | +| `duration_s` | integer | no | Duration, in seconds, that the core will be utilised. Defaults to 30s | + +```bash +curl http://localhost:3000/-/chaos/cpu_spin?duration_s=60 --header 'X-Chaos-Secret: secret' +curl http://localhost:3000/-/chaos/cpu_spin?duration_s=60&token=secret +``` + +## DB spin + +This endpoint attempts to fully utilise a single core, and interleave it with DB request, for the given period. +This endpoint can be used to model yielding execution to another threads when running concurrently. + +Depending on your rack server setup, your request may timeout after a predermined period (normally 60 seconds). +If you're using Unicorn, this is done by killing the worker process. + +``` +GET /-/chaos/db_spin +GET /-/chaos/db_spin?duration_s=50 ``` | Attribute | Type | Required | Description | | ------------ | ------- | -------- | --------------------------------------------------------------------- | +| `interval_s` | float | no | Interval, in seconds, for every DB request. Defaults to 1s | | `duration_s` | integer | no | Duration, in seconds, that the core will be utilised. Defaults to 30s | ```bash -curl http://localhost:3000/-/chaos/cpuspin?duration_s=60 --header 'X-Chaos-Secret: secret' +curl http://localhost:3000/-/chaos/db_spin?interval_s=1&duration_s=60 --header 'X-Chaos-Secret: secret' +curl http://localhost:3000/-/chaos/db_spin?interval_s=1&duration_s=60&token=secret ``` ## Sleep -This endpoint is similar to the CPU Spin endpoint but simulates off-processor activity, such as network calls to backend services. It will sleep for a given duration. +This endpoint is similar to the CPU Spin endpoint but simulates off-processor activity, such as network calls to backend services. It will sleep for a given duration_s. -As with the CPU Spin endpoint, this may lead to your request timing out if duration exceeds the configured limit. +As with the CPU Spin endpoint, this may lead to your request timing out if duration_s exceeds the configured limit. ``` GET /-/chaos/sleep @@ -99,6 +120,7 @@ GET /-/chaos/sleep?duration_s=50 ```bash curl http://localhost:3000/-/chaos/sleep?duration_s=60 --header 'X-Chaos-Secret: secret' +curl http://localhost:3000/-/chaos/sleep?duration_s=60&token=secret ``` ## Kill @@ -114,4 +136,5 @@ GET /-/chaos/kill ```bash curl http://localhost:3000/-/chaos/kill --header 'X-Chaos-Secret: secret' +curl http://localhost:3000/-/chaos/kill?token=secret ``` diff --git a/doc/development/chatops_on_gitlabcom.md b/doc/development/chatops_on_gitlabcom.md index a7b402c3fb0..3b681880401 100644 --- a/doc/development/chatops_on_gitlabcom.md +++ b/doc/development/chatops_on_gitlabcom.md @@ -13,10 +13,10 @@ tasks such as: To request access to Chatops on GitLab.com: 1. Log into <https://ops.gitlab.net/users/sign_in> using the same username as for GitLab.com. -1. Ask [anyone in the `chatops` project](https://gitlab.com/gitlab-com/chatops/project_members) to add you by running `/chatops run member add <username> gitlab-com/chatops --ops`. +1. Ask [anyone in the `chatops` project](https://gitlab.com/gitlab-com/chatops/-/project_members) to add you by running `/chatops run member add <username> gitlab-com/chatops --ops`. ## See also - - [Chatops Usage](https://docs.gitlab.com/ee/ci/chatops/README.html) - - [Understanding EXPLAIN plans](understanding_explain_plans.md) - - [Feature Groups](feature_flags/development.md#feature-groups) +- [Chatops Usage](../ci/chatops/README.md) +- [Understanding EXPLAIN plans](understanding_explain_plans.md) +- [Feature Groups](feature_flags/development.md#feature-groups) diff --git a/doc/development/code_comments.md b/doc/development/code_comments.md index 36962eb46d4..827a610efa2 100644 --- a/doc/development/code_comments.md +++ b/doc/development/code_comments.md @@ -1,11 +1,11 @@ # Code comments -Whenever you add comment to the code that is expected to be addressed at any time -in future, please create a technical debt issue for it. Then put a link to it +Whenever you add comment to the code that is expected to be addressed at any time +in future, please create a technical debt issue for it. Then put a link to it to the code comment you've created. This will allow other developers to quickly check if a comment is still relevant and what needs to be done to address it. -Examples: +Examples: ```rb # Deprecated scope until code_owner column has been migrated to rule_type. diff --git a/doc/development/code_review.md b/doc/development/code_review.md index 6123f9f845a..e60800f1ab7 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -319,7 +319,7 @@ reviewee. ### GitLab-specific concerns GitLab is used in a lot of places. Many users use -our [Omnibus packages](https://about.gitlab.com/installation/), but some use +our [Omnibus packages](https://about.gitlab.com/install/), but some use the [Docker images](https://docs.gitlab.com/omnibus/docker/), some are [installed from source](../install/installation.md), and there are other installation methods available. GitLab.com itself is a large diff --git a/doc/development/contributing/community_roles.md b/doc/development/contributing/community_roles.md index b9c369286d2..3296cb173d7 100644 --- a/doc/development/contributing/community_roles.md +++ b/doc/development/contributing/community_roles.md @@ -4,8 +4,8 @@ GitLab community members and their privileges/responsibilities. | Roles | Responsibilities | Requirements | |-------|------------------|--------------| -| Maintainer | Accepts merge requests on several GitLab projects | Added to the [team page](https://about.gitlab.com/team/). An expert on code reviews and knows the product/code base | -| Reviewer | Performs code reviews on MRs | Added to the [team page](https://about.gitlab.com/team/) | +| Maintainer | Accepts merge requests on several GitLab projects | Added to the [team page](https://about.gitlab.com/company/team/). An expert on code reviews and knows the product/code base | +| Reviewer | Performs code reviews on MRs | Added to the [team page](https://about.gitlab.com/company/team/) | | Developer |Has access to GitLab internal infrastructure & issues (e.g. HR-related) | GitLab employee or a Core Team member (with an NDA) | | Contributor | Can make contributions to all GitLab public projects | Have a GitLab.com account | diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md index 59cf5014da4..853882e8642 100644 --- a/doc/development/contributing/index.md +++ b/doc/development/contributing/index.md @@ -4,7 +4,7 @@ Thank you for your interest in contributing to GitLab. This guide details how to contribute to GitLab in a way that is easy for everyone. For a first-time step-by-step guide to the contribution process, please see -["Contributing to GitLab"](https://about.gitlab.com/contributing/). +["Contributing to GitLab"](https://about.gitlab.com/community/contribute/). Looking for something to work on? Look for issues with the label [`Accepting merge requests`](#i-want-to-contribute). diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md index 27c349c03aa..d0562cd2bbd 100644 --- a/doc/development/contributing/issue_workflow.md +++ b/doc/development/contributing/issue_workflow.md @@ -1,7 +1,7 @@ # Workflow labels To allow for asynchronous issue handling, we use [milestones][milestones-page] -and [labels][labels-page]. Leads and product managers handle most of the +and [labels](https://gitlab.com/gitlab-org/gitlab-ce/-/labels). Leads and product managers handle most of the scheduling into milestones. Labelling is a task for everyone. Most issues will have labels for at least one of the following: @@ -18,7 +18,7 @@ Most issues will have labels for at least one of the following: - Severity: ~S1, ~S2, ~S3, ~S4 All labels, their meaning and priority are defined on the -[labels page][labels-page]. +[labels page](https://gitlab.com/gitlab-org/gitlab-ce/-/labels). If you come across an issue that has none of these, and you're allowed to set labels, you can _always_ add the team and type, and often also the subject. @@ -38,7 +38,7 @@ makes them float to the top, depending on their importance. Type labels are always lowercase, and can have any color, besides blue (which is already reserved for subject labels). -The descriptions on the [labels page][labels-page] explain what falls under each type label. +The descriptions on the [labels page](https://gitlab.com/gitlab-org/gitlab-ce/-/labels) explain what falls under each type label. ## Subject labels @@ -58,9 +58,9 @@ issue is labeled with a subject label corresponding to your expertise. Subject labels are always all-lowercase. -## Team labels +## Team labels -**Important**: Most of the team labels will be soon deprecated in favor of [Group labels](#group-labels). +**Important**: Most of the team labels will be soon deprecated in favor of [Group labels](#group-labels). Team labels specify what team is responsible for this issue. Assigning a team label makes sure issues get the attention of the appropriate @@ -89,7 +89,7 @@ The following team labels are **true** teams per our [organization structure](ht - ~Delivery - ~Documentation -The descriptions on the [labels page][labels-page] explain what falls under the +The descriptions on the [labels page](https://gitlab.com/gitlab-org/gitlab-ce/-/labels) explain what falls under the responsibility of each team. Within those team labels, we also have the ~backend and ~frontend labels to @@ -98,7 +98,6 @@ indicate if an issue needs backend work, frontend work, or both. Team labels are always capitalized so that they show up as the first label for any issue. - ## Stage labels Stage labels specify which [DevOps stage][devops-stages] the issue belongs to. @@ -141,43 +140,42 @@ Group labels specify which [groups][structure-groups] the issue belongs to. The current group labels are: -* ~"group::access" -* ~"group::measure" -* ~"group::source code" -* ~"group::knowledge" -* ~"group::editor" -* ~"group::gitaly" -* ~"group::gitter" -* ~"group::team planning" -* ~"group::enterprise planning" -* ~"group::certify" -* ~"group::ci and runner" -* ~"group::testing" -* ~"group::package" -* ~"group::progressive delivery" -* ~"group::release management" -* ~"group::autodevops and kubernetes" -* ~"group::serverless and paas" -* ~"group::apm" -* ~"group::health" -* ~"group::static analysis" -* ~"group::dynamic analysis" -* ~"group::software composition analysis" -* ~"group::runtime application security" -* ~"group::threat management" -* ~"group::application infrastructure security" -* ~"group::activation" -* ~"group::adoption" -* ~"group::upsell" -* ~"group::retention" -* ~"group::fulfillment" -* ~"group::telemetry" -* ~"group::distribution" -* ~"group::geo" -* ~"group::memory" -* ~"group::ecosystem" +- ~"group::access" +- ~"group::measure" +- ~"group::source code" +- ~"group::knowledge" +- ~"group::editor" +- ~"group::gitaly" +- ~"group::gitter" +- ~"group::team planning" +- ~"group::enterprise planning" +- ~"group::certify" +- ~"group::ci and runner" +- ~"group::testing" +- ~"group::package" +- ~"group::progressive delivery" +- ~"group::release management" +- ~"group::autodevops and kubernetes" +- ~"group::serverless and paas" +- ~"group::apm" +- ~"group::health" +- ~"group::static analysis" +- ~"group::dynamic analysis" +- ~"group::software composition analysis" +- ~"group::runtime application security" +- ~"group::threat management" +- ~"group::application infrastructure security" +- ~"group::activation" +- ~"group::adoption" +- ~"group::upsell" +- ~"group::retention" +- ~"group::fulfillment" +- ~"group::telemetry" +- ~"group::distribution" +- ~"group::geo" +- ~"group::memory" +- ~"group::ecosystem" - These labels are [scoped labels](../../user/project/labels.md#scoped-labels-premium) and thus are mutually exclusive. @@ -192,15 +190,15 @@ can be applied to a single issue. You can find the groups listed in the The current department labels are: -* ~UX -* ~Quality +- ~UX +- ~Quality ## Specialization labels These labels narrow the [specialization](https://about.gitlab.com/company/team/structure/#specialist) on a unit of work. -* ~frontend -* ~backend +- ~frontend +- ~backend ## Release Scoping labels @@ -248,9 +246,9 @@ There can be multiple facets of the impact. The below is a guideline. If a bug seems to fall between two severity labels, assign it to the higher-severity label. - Example(s) of ~S1 - - Data corruption/loss. + - Data corruption/loss. - Security breach. - - Unable to create an issue or merge request. + - Unable to create an issue or merge request. - Unable to add a comment or discussion to the issue or merge request. - Example(s) of ~S2 - Cannot submit changes through the web IDE but the commandline works. @@ -500,7 +498,6 @@ A recent example of this was the issue for [Return to Contributing documentation](index.md) -[labels-page]: https://gitlab.com/gitlab-org/gitlab-ce/labels [ce-tracker]: https://gitlab.com/gitlab-org/gitlab-ce/issues [ee-tracker]: https://gitlab.com/gitlab-org/gitlab-ee/issues [inferred-labels]: https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/155 diff --git a/doc/development/contributing/style_guides.md b/doc/development/contributing/style_guides.md index 87e61a7476f..5c6ea1f469d 100644 --- a/doc/development/contributing/style_guides.md +++ b/doc/development/contributing/style_guides.md @@ -1,11 +1,11 @@ # Style guides -1. [Ruby](https://github.com/bbatsov/ruby-style-guide). +1. [Ruby](https://github.com/rubocop-hq/ruby-style-guide). Important sections include [Source Code Layout][rss-source] and [Naming][rss-naming]. Use: - multi-line method chaining style **Option A**: dot `.` on the second line - string literal quoting style **Option A**: single quoted by default -1. [Rails](https://github.com/bbatsov/rails-style-guide) +1. [Rails](https://github.com/rubocop-hq/rails-style-guide) 1. [Newlines styleguide][newlines-styleguide] 1. [Testing][testing] 1. [JavaScript styleguide][js-styleguide] @@ -13,7 +13,7 @@ 1. [Shell commands (Ruby)](../shell_commands.md) created by GitLab contributors to enhance security 1. [Database Migrations](../migration_style_guide.md) -1. [Markdown](http://www.cirosantilli.com/markdown-styleguide) +1. [Markdown](https://cirosantilli.com/markdown-style-guide/) 1. [Documentation styleguide](../documentation/styleguide.md) 1. Interface text should be written subjectively instead of objectively. It should be the GitLab core team addressing a person. It should be written in @@ -25,7 +25,7 @@ 1. [Python](../python_guide/index.md) This is also the style used by linting tools such as -[RuboCop](https://github.com/bbatsov/rubocop) and [Hound CI](https://houndci.com). +[RuboCop](https://github.com/rubocop-hq/rubocop) and [Hound CI](https://houndci.com). --- diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md index 418e58b22d5..36a2f47a55b 100644 --- a/doc/development/documentation/index.md +++ b/doc/development/documentation/index.md @@ -18,7 +18,7 @@ In addition to this page, the following resources to help craft and contribute d ## Source files and rendered web locations -Documentation for GitLab Community Edition (CE) and Enterprise Edition (EE), along with GitLab Runner and Omnibus, is published to [docs.gitlab.com](https://docs.gitlab.com). The documentation for CE and EE is also published within the application at `/help` on the domain of the GitLab instance. +Documentation for GitLab Community Edition (CE) and Enterprise Edition (EE), along with GitLab Runner and Omnibus, is published to [docs.gitlab.com](https://docs.gitlab.com). The documentation for CE and EE is also published within the application at `/help` on the domain of the GitLab instance, though there are [plans](https://gitlab.com/groups/gitlab-org/-/epics/693) to end this practice and instead link out from the GitLab application to docs.gitlab.com URLs. At `/help`, only content for your current edition and version is included, whereas multiple versions' content is available at docs.gitlab.com. @@ -43,7 +43,7 @@ Meanwhile, anyone can contribute [documentation improvements](improvement-workfl ## Markdown and styles -[GitLab docs](https://gitlab.com/gitlab-com/gitlab-docs) uses [GitLab Kramdown](https://gitlab.com/gitlab-org/gitlab_kramdown) +[GitLab docs](https://gitlab.com/gitlab-org/gitlab-docs) uses [GitLab Kramdown](https://gitlab.com/gitlab-org/gitlab_kramdown) as its markdown rendering engine. See the [GitLab Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/) for a complete Kramdown reference. Adhere to the [Documentation Style Guide](styleguide.md). If a style standard is missing, you are welcome to suggest one via a merge request. @@ -274,8 +274,11 @@ Follow this [method for cherry-picking from CE to EE](../automatic_ce_ee_merge.m ## GitLab `/help` -Every GitLab instance includes the documentation, which is available from `/help` -(`http://my-instance.com/help`), e.g., <https://gitlab.com/help>. +Every GitLab instance includes the documentation, which is available at `/help` +(`https://gitlab.example.com/help`). For example, <https://gitlab.com/help>. + +There are [plans](https://gitlab.com/groups/gitlab-org/-/epics/693) to end this +practice and instead link out from the GitLab application to docs.gitlab.com URLs. The documentation available online on docs.gitlab.com is continuously deployed every hour from the `master` branch of CE, EE, Omnibus, and Runner. Therefore, @@ -381,7 +384,7 @@ on how the left-side navigation menu is built and updated. NOTE: **Note:** To preview your changes to documentation locally, follow this -[development guide](https://gitlab.com/gitlab-com/gitlab-docs/blob/master/README.md#development-when-contributing-to-gitlab-documentation) or [these instructions for GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/gitlab_docs.md). +[development guide](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/README.md#development-when-contributing-to-gitlab-documentation) or [these instructions for GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/gitlab_docs.md). The live preview is currently enabled for the following projects: @@ -405,7 +408,7 @@ You will need to push a branch to those repositories, it doesn't work for forks. The `review-docs-deploy*` job will: -1. Create a new branch in the [gitlab-docs](https://gitlab.com/gitlab-com/gitlab-docs) +1. Create a new branch in the [gitlab-docs](https://gitlab.com/gitlab-org/gitlab-docs) project named after the scheme: `$DOCS_GITLAB_REPO_SUFFIX-$CI_ENVIRONMENT_SLUG`, where `DOCS_GITLAB_REPO_SUFFIX` is the suffix for each product, e.g, `ce` for CE, etc. @@ -461,7 +464,7 @@ If you want to know the in-depth details, here's what's really happening: 1. The preview URL is shown both at the job output and in the merge request widget. You also get the link to the remote pipeline. 1. In the docs project, the pipeline is created and it - [skips the test jobs](https://gitlab.com/gitlab-com/gitlab-docs/blob/8d5d5c750c602a835614b02f9db42ead1c4b2f5e/.gitlab-ci.yml#L50-55) + [skips the test jobs](https://gitlab.com/gitlab-org/gitlab-docs/blob/8d5d5c750c602a835614b02f9db42ead1c4b2f5e/.gitlab-ci.yml#L50-55) to lower the build time. 1. Once the docs site is built, the HTML files are uploaded as artifacts. 1. A specific Runner tied only to the docs project, runs the Review App job @@ -485,7 +488,7 @@ Currently, the following tests are in place: that all cURL examples in API docs use the full switches. It's recommended to [check locally](#previewing-the-changes-live) before pushing to GitLab by executing the command `bundle exec nanoc check internal_links` on your local - [`gitlab-docs`](https://gitlab.com/gitlab-com/gitlab-docs) directory. + [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs) directory. 1. [`ee_compat_check`](../automatic_ce_ee_merge.md#avoiding-ce-ee-merge-conflicts-beforehand) (runs on CE only): When you submit a merge request to GitLab Community Edition (CE), there is this additional job that runs against Enterprise Edition (EE) diff --git a/doc/development/documentation/site_architecture/global_nav.md b/doc/development/documentation/site_architecture/global_nav.md index 20eeebf444f..753a636a779 100644 --- a/doc/development/documentation/site_architecture/global_nav.md +++ b/doc/development/documentation/site_architecture/global_nav.md @@ -4,9 +4,9 @@ description: "Learn how GitLab docs' global navigation works and how to add new # Global navigation -> - [Introduced](https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/362) +> - [Introduced](https://gitlab.com/gitlab-org/gitlab-docs/merge_requests/362) in GitLab 11.6. -> - [Updated](https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/482) in GitLab 12.1. +> - [Updated](https://gitlab.com/gitlab-org/gitlab-docs/merge_requests/482) in GitLab 12.1. The global nav adds to the left sidebar the ability to navigate and explore the contents of GitLab's documentation. @@ -25,7 +25,7 @@ To add a new doc to the nav, first and foremost, check with the technical writin Once you get their approval and their guidance in regards to the position on the nav, read trhough this page to understand how it works, and submit a merge request to the docs site, adding the doc you wish to include in the nav into the -[global nav data file](https://gitlab.com/gitlab-com/gitlab-docs/blob/master/content/_data/global-nav.yaml). +[global nav data file](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/content/_data/global-nav.yaml). Don't forget to ask a technical writer to review your changes before merging. @@ -70,7 +70,7 @@ the data among the nav in containers properly [styled](#css-classes). ### Data file -The [data file](https://gitlab.com/gitlab-com/gitlab-docs/blob/master/content/_data/global-nav.yaml) +The [data file](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/content/_data/global-nav.yaml) is structured in three components: sections, categories, and docs. #### Sections @@ -248,9 +248,9 @@ Examples: ### Layout file (logic) -The [layout](https://gitlab.com/gitlab-com/gitlab-docs/blob/master/layouts/global_nav.html) +The [layout](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/layouts/global_nav.html) is fed by the [data file](#data-file), builds the global nav, and is rendered by the -[default](https://gitlab.com/gitlab-com/gitlab-docs/blob/master/layouts/default.html) layout. +[default](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/layouts/default.html) layout. There are three main considerations on the logic built for the nav: diff --git a/doc/development/documentation/site_architecture/index.md b/doc/development/documentation/site_architecture/index.md index 6dd12b5efa7..1aef0ed855c 100644 --- a/doc/development/documentation/site_architecture/index.md +++ b/doc/development/documentation/site_architecture/index.md @@ -4,14 +4,14 @@ description: "Learn how GitLab's documentation website is architectured." # Documentation site architecture -Learn how we build and architecture [`gitlab-docs`](https://gitlab.com/gitlab-com/gitlab-docs) +Learn how we build and architecture [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs) and deploy it to <https://docs.gitlab.com>. ## Repository While the source of the documentation content is stored in GitLab's respective product repositories, the source that is used to build the documentation site _from that content_ -is located at <https://gitlab.com/gitlab-com/gitlab-docs>. +is located at <https://gitlab.com/gitlab-org/gitlab-docs>. The following diagram illustrates the relationship between the repositories from where content is sourced, the `gitlab-docs` project, and the published output. @@ -43,7 +43,7 @@ from where content is sourced, the `gitlab-docs` project, and the published outp G --> L ``` -See the [README there](https://gitlab.com/gitlab-com/gitlab-docs/blob/master/README.md) +See the [README there](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/README.md) for detailed information. ## Assets @@ -76,7 +76,7 @@ read through the [global navigation](global_nav.md) doc. The docs site is deployed to production with GitLab Pages, and previewed in merge requests with Review Apps. -The deployment aspects will be soon transferred from the [original document](https://gitlab.com/gitlab-com/gitlab-docs/blob/master/README.md) +The deployment aspects will be soon transferred from the [original document](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/README.md) to this page. <!-- diff --git a/doc/development/documentation/structure.md b/doc/development/documentation/structure.md index fe676efa94d..025a946da0e 100644 --- a/doc/development/documentation/structure.md +++ b/doc/development/documentation/structure.md @@ -127,7 +127,7 @@ Notes: ## Help and feedback section -The "help and feedback" section (introduced by [!319](https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/319)) displayed at the end of each document +The "help and feedback" section (introduced by [!319](https://gitlab.com/gitlab-org/gitlab-docs/merge_requests/319)) displayed at the end of each document can be omitted from the doc by adding a key into the its frontmatter: ```yaml @@ -142,7 +142,7 @@ you must check with a technical writer before doing so. ### Disqus We also have integrated the docs site with Disqus (introduced by -[!151](https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/151)), +[!151](https://gitlab.com/gitlab-org/gitlab-docs/merge_requests/151)), allowing our users to post comments. To omit only the comments from the feedback section, use the following diff --git a/doc/development/documentation/styleguide.md b/doc/development/documentation/styleguide.md index 6bfedcb1047..1ca965f8ae9 100644 --- a/doc/development/documentation/styleguide.md +++ b/doc/development/documentation/styleguide.md @@ -340,7 +340,7 @@ For other punctuation rules, please refer to the links shift too, which eventually leads to dead links. If you think it is compelling to add numbers in headings, make sure to at least discuss it with someone in the Merge Request. -- [Avoid using symbols and special chars](https://gitlab.com/gitlab-com/gitlab-docs/issues/84) +- [Avoid using symbols and special chars](https://gitlab.com/gitlab-org/gitlab-docs/issues/84) in headers. Whenever possible, they should be plain and short text. - Avoid adding things that show ephemeral statuses. For example, if a feature is considered beta or experimental, put this info in a note, not in the heading. @@ -393,7 +393,7 @@ Instead: Example: ```md -For more information, see the [confidential issue](https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html) `https://gitlab.com/gitlab-org/gitlab-ce/issues/<issue_number>`. +For more information, see the [confidential issue](../../user/project/issues/confidential_issues.md) `https://gitlab.com/gitlab-org/gitlab-ce/issues/<issue_number>`. ``` ### Unlinking emails @@ -488,7 +488,7 @@ You can link any up-to-date video that is useful to the GitLab user. ### Embed videos -> [Introduced](https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/472) in GitLab 12.1. +> [Introduced](https://gitlab.com/gitlab-org/gitlab-docs/merge_requests/472) in GitLab 12.1. GitLab docs (docs.gitlab.com) support embedded videos. @@ -518,7 +518,7 @@ you have your MR reviewed and approved by a technical writer. ```html leave a blank line here <div class="video-fallback"> - See the video: [Video title](https://www.youtube.com/watch?v=MqL6BMOySIQ). + See the video: <a href="https://www.youtube.com/watch?v=MqL6BMOySIQ">Video title</a>. </div> <figure class="video-container"> <iframe src="https://www.youtube.com/embed/MqL6BMOySIQ" frameborder="0" allowfullscreen="true"> </iframe> @@ -529,7 +529,7 @@ leave a blank line here This is how it renders on docs.gitlab.com: <div class="video-fallback"> - See the video: [What is GitLab](https://www.youtube.com/watch?v=enMumwvLAug). + See the video: <a href="https://www.youtube.com/watch?v=enMumwvLAug">What is GitLab</a>. </div> <figure class="video-container"> <iframe src="https://www.youtube.com/embed/MqL6BMOySIQ" frameborder="0" allowfullscreen="true"> </iframe> @@ -767,24 +767,24 @@ Other text includes deprecation notices and version-specific how-to information. When a feature is available in EE-only tiers, add the corresponding tier according to the feature availability: -- For GitLab Starter and GitLab.com Bronze: `**[STARTER]**`. -- For GitLab Premium and GitLab.com Silver: `**[PREMIUM]**`. -- For GitLab Ultimate and GitLab.com Gold: `**[ULTIMATE]**`. -- For GitLab Core and GitLab.com Free: `**[CORE]**`. +- For GitLab Starter and GitLab.com Bronze: `**(STARTER)**`. +- For GitLab Premium and GitLab.com Silver: `**(PREMIUM)**`. +- For GitLab Ultimate and GitLab.com Gold: `**(ULTIMATE)**`. +- For GitLab Core and GitLab.com Free: `**(CORE)**`. To exclude GitLab.com tiers (when the feature is not available in GitLab.com), add the keyword "only": -- For GitLab Core: `**[CORE ONLY]**`. -- For GitLab Starter: `**[STARTER ONLY]**`. -- For GitLab Premium: `**[PREMIUM ONLY]**`. -- For GitLab Ultimate: `**[ULTIMATE ONLY]**`. +- For GitLab Core: `**(CORE ONLY)**`. +- For GitLab Starter: `**(STARTER ONLY)**`. +- For GitLab Premium: `**(PREMIUM ONLY)**`. +- For GitLab Ultimate: `**(ULTIMATE ONLY)**`. For GitLab.com only tiers (when the feature is not available for self-hosted instances): -- For GitLab Bronze and higher tiers: `**[BRONZE ONLY]**`. -- For GitLab Silver and higher tiers: `**[SILVER ONLY]**`. -- For GitLab Gold: `**[GOLD ONLY]**`. +- For GitLab Bronze and higher tiers: `**(BRONZE ONLY)**`. +- For GitLab Silver and higher tiers: `**(SILVER ONLY)**`. +- For GitLab Gold: `**(GOLD ONLY)**`. The tier should be ideally added to headers, so that the full badge will be displayed. However, it can be also mentioned from paragraphs, list items, and table cells. For these cases, @@ -792,17 +792,17 @@ the tier mention will be represented by an orange question mark that will show t For example: -- `**[STARTER]**` renders as **[STARTER]** -- `**[STARTER ONLY]**` renders as **[STARTER ONLY]** -- `**[SILVER ONLY]**` renders as **[SILVER ONLY]** +- `**(STARTER)**` renders as **(STARTER)** +- `**(STARTER ONLY)**` renders as **(STARTER ONLY)** +- `**(SILVER ONLY)**` renders as **(SILVER ONLY)** The absence of tiers' mentions mean that the feature is available in GitLab Core, GitLab.com Free, and all higher tiers. ### How it works -Introduced by [!244](https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/244), -the special markup `**[STARTER]**` will generate a `span` element to trigger the +Introduced by [!244](https://gitlab.com/gitlab-org/gitlab-docs/merge_requests/244), +the special markup `**(STARTER)**` will generate a `span` element to trigger the badges and tooltips (`<span class="badge-trigger starter">`). When the keyword "only" is added, the corresponding GitLab.com badge will not be displayed. diff --git a/doc/development/documentation/workflow.md b/doc/development/documentation/workflow.md index 0abfe4b82a4..9f488fac7d0 100644 --- a/doc/development/documentation/workflow.md +++ b/doc/development/documentation/workflow.md @@ -6,5 +6,5 @@ description: Learn the processes for contributing to GitLab's documentation. Documentation workflows at GitLab differ depending on the reason for the change: -- [Documentation process for feature changes](feature-change-workflow.md) - The documentation is being created or updated as part of the development and release of a new or enhanced feature. This process involves the developer of the feature (who includes new/updated documentation files as part of the same merge request containing the feature's code) and also involves the product manager and technical writer who are listed for the feature's [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages). +- [Documentation process for feature changes](feature-change-workflow.md) - The documentation is being created or updated as part of the development and release of a new or enhanced feature. This process involves the developer of the feature (who includes new/updated documentation files as part of the same merge request containing the feature's code) and also involves the product manager and technical writer who are listed for the feature's [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages). - [Documentation improvement workflow](improvement-workflow.md) - All documentation additions not associated with a feature release. Documentation is being created or updated to improve accuracy, completeness, ease of use, or any reason other than a feature change. Anyone (and everyone) can contribute a merge request for this type of change at any time. diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md index 6f4a36d4066..7131b717353 100644 --- a/doc/development/ee_features.md +++ b/doc/development/ee_features.md @@ -182,52 +182,52 @@ There are a few gotchas with it: pattern](https://en.wikipedia.org/wiki/Template_method_pattern). For example, given this base: - ```ruby - class Base - def execute - return unless enabled? + ```ruby + class Base + def execute + return unless enabled? - # ... - # ... - end + # ... + # ... end - ``` + end + ``` - Instead of just overriding `Base#execute`, we should update it and extract - the behaviour into another method: + Instead of just overriding `Base#execute`, we should update it and extract + the behaviour into another method: - ```ruby - class Base - def execute - return unless enabled? + ```ruby + class Base + def execute + return unless enabled? - do_something - end + do_something + end - private + private - def do_something - # ... - # ... - end + def do_something + # ... + # ... end - ``` + end + ``` - Then we're free to override that `do_something` without worrying about the - guards: + Then we're free to override that `do_something` without worrying about the + guards: - ```ruby - module EE::Base - extend ::Gitlab::Utils::Override + ```ruby + module EE::Base + extend ::Gitlab::Utils::Override - override :do_something - def do_something - # Follow the above pattern to call super and extend it - end + override :do_something + def do_something + # Follow the above pattern to call super and extend it end - ``` + end + ``` - This would require updating CE first, or make sure this is back ported to CE. + This would require updating CE first, or make sure this is back ported to CE. When prepending, place them in the `ee/` specific sub-directory, and wrap class or module in `module EE` to avoid naming conflicts. @@ -446,7 +446,6 @@ The disadvantage of this: port `render_if_exists` to CE. - If we have typos in the partial name, it would be silently ignored. - ##### Caveats The `render_if_exists` view path argument must be relative to `app/views/` and `ee/app/views`. @@ -973,7 +972,7 @@ For regular JS files, the approach is similar. 1. An EE file should be created with the EE only code, and it should extend the CE counterpart. 1. For code inside functions that can't be extended, the code should be moved into a new file and we should use `ee_else_ce` helper: -##### Example: +#### Example: ```javascript import eeCode from 'ee_else_ce/ee_code'; @@ -1000,7 +999,7 @@ styles are usually kept in stylesheet that is common for both CE and EE, and it to isolate such ruleset from rest of CE rules (along with adding comment describing the same) to avoid conflicts during CE to EE merge. -#### Bad +### Bad ```scss .section-body { @@ -1016,7 +1015,7 @@ to avoid conflicts during CE to EE merge. } ``` -#### Good +### Good ```scss .section-body { @@ -1034,13 +1033,13 @@ to avoid conflicts during CE to EE merge. // EE-specific end ``` -### Backporting changes from EE to CE +## Backporting changes from EE to CE Until the work completed to merge the ce and ee codebases, which is tracked on [epic &802](https://gitlab.com/groups/gitlab-org/-/epics/802), there exists times in which some changes for EE require specific changes to the CE code base. Examples of backports include the following: -* Features intended or originally built for EE that are later decided to move to CE -* Sometimes some code in CE may impact the EE feature +- Features intended or originally built for EE that are later decided to move to CE +- Sometimes some code in CE may impact the EE feature Here is a workflow to make sure those changes end up backported safely into CE too. diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md index e5da47ba16e..0965db29557 100644 --- a/doc/development/elasticsearch.md +++ b/doc/development/elasticsearch.md @@ -1,4 +1,4 @@ -# Elasticsearch knowledge **[STARTER ONLY]** +# Elasticsearch knowledge **(STARTER ONLY)** This area is to maintain a compendium of useful information when working with elasticsearch. diff --git a/doc/development/emails.md b/doc/development/emails.md index 8baf343b133..e6af075a282 100644 --- a/doc/development/emails.md +++ b/doc/development/emails.md @@ -26,57 +26,57 @@ See the [Rails guides] for more info. feature and fill in the details for your specific IMAP server and email account: - Configuration for Gmail / Google Apps, assumes mailbox gitlab-incoming@gmail.com - - ```yaml - incoming_email: - enabled: true - - # The email address including the `%{key}` placeholder that will be replaced to reference the item being replied to. - # The placeholder can be omitted but if present, it must appear in the "user" part of the address (before the `@`). - address: "gitlab-incoming+%{key}@gmail.com" - - # Email account username - # With third party providers, this is usually the full email address. - # With self-hosted email servers, this is usually the user part of the email address. - user: "gitlab-incoming@gmail.com" - # Email account password - password: "[REDACTED]" - - # IMAP server host - host: "imap.gmail.com" - # IMAP server port - port: 993 - # Whether the IMAP server uses SSL - ssl: true - # Whether the IMAP server uses StartTLS - start_tls: false - - # The mailbox where incoming mail will end up. Usually "inbox". - mailbox: "inbox" - # The IDLE command timeout. - idle_timeout: 60 - ``` - - As mentioned, the part after `+` is ignored, and this will end up in the mailbox for `gitlab-incoming@gmail.com`. + Configuration for Gmail / Google Apps, assumes mailbox `gitlab-incoming@gmail.com`: + + ```yaml + incoming_email: + enabled: true + + # The email address including the `%{key}` placeholder that will be replaced to reference the item being replied to. + # The placeholder can be omitted but if present, it must appear in the "user" part of the address (before the `@`). + address: "gitlab-incoming+%{key}@gmail.com" + + # Email account username + # With third party providers, this is usually the full email address. + # With self-hosted email servers, this is usually the user part of the email address. + user: "gitlab-incoming@gmail.com" + # Email account password + password: "[REDACTED]" + + # IMAP server host + host: "imap.gmail.com" + # IMAP server port + port: 993 + # Whether the IMAP server uses SSL + ssl: true + # Whether the IMAP server uses StartTLS + start_tls: false + + # The mailbox where incoming mail will end up. Usually "inbox". + mailbox: "inbox" + # The IDLE command timeout. + idle_timeout: 60 + ``` + + As mentioned, the part after `+` is ignored, and this will end up in the mailbox for `gitlab-incoming@gmail.com`. 1. Run this command in the GitLab root directory to launch `mail_room`: - ```sh - bundle exec mail_room -q -c config/mail_room.yml - ``` + ```sh + bundle exec mail_room -q -c config/mail_room.yml + ``` 1. Verify that everything is configured correctly: - ```sh - bundle exec rake gitlab:incoming_email:check RAILS_ENV=development - ``` + ```sh + bundle exec rake gitlab:incoming_email:check RAILS_ENV=development + ``` 1. Reply by email should now be working. ## Email namespace -As of GitLab 11.7, we support a new format for email handler addresses. This was done to +As of GitLab 11.7, we support a new format for email handler addresses. This was done to support catch-all mailboxes. If you need to implement a feature which requires a new email handler, follow these rules @@ -91,10 +91,10 @@ for the format of the email key: Examples of valid email keys: - - `gitlab-org-gitlab-ce-20-Author_Token12345678-issue` (create a new issue) - - `gitlab-org-gitlab-ce-20-Author_Token12345678-merge-request` (create a new merge request) - - `1234567890abcdef1234567890abcdef-unsubscribe` (unsubscribe from a conversation) - - `1234567890abcdef1234567890abcdef` (reply to a conversation) +- `gitlab-org-gitlab-ce-20-Author_Token12345678-issue` (create a new issue) +- `gitlab-org-gitlab-ce-20-Author_Token12345678-merge-request` (create a new merge request) +- `1234567890abcdef1234567890abcdef-unsubscribe` (unsubscribe from a conversation) +- `1234567890abcdef1234567890abcdef` (reply to a conversation) Please note that the action `-issue-` is used in GitLab Premium as the handler for the Service Desk feature. @@ -103,10 +103,10 @@ Please note that the action `-issue-` is used in GitLab Premium as the handler f Although we continue to support the older legacy format, no new features should use a legacy format. These are the only valid legacy formats for an email handler: - - `path/to/project+namespace` - - `path/to/project+namespace+action` - - `namespace` - - `namespace+action` +- `path/to/project+namespace` +- `path/to/project+namespace+action` +- `namespace` +- `namespace+action` Please note that `path/to/project` is used in GitLab Premium as handler for the Service Desk feature. diff --git a/doc/development/fe_guide/architecture.md b/doc/development/fe_guide/architecture.md index c67389b169e..49b74b5ebcf 100644 --- a/doc/development/fe_guide/architecture.md +++ b/doc/development/fe_guide/architecture.md @@ -11,7 +11,7 @@ Architectural decisions should be accessible to everyone, so please document them in the relevant Merge Request discussion or by updating our documentation when appropriate. -You can find the Frontend Architecture experts on the [team page](https://about.gitlab.com/team). +You can find the Frontend Architecture experts on the [team page](https://about.gitlab.com/company/team). ## Examples diff --git a/doc/development/fe_guide/design_patterns.md b/doc/development/fe_guide/design_patterns.md index 0342d16a87c..2f372f783f5 100644 --- a/doc/development/fe_guide/design_patterns.md +++ b/doc/development/fe_guide/design_patterns.md @@ -53,6 +53,7 @@ When writing a class that needs to manipulate the DOM guarantee a container opti This is useful when we need that class to be instantiated more than once in the same page. Bad: + ```javascript class Foo { constructor() { @@ -63,6 +64,7 @@ new Foo(); ``` Good: + ```javascript class Foo { constructor(opts) { @@ -72,6 +74,7 @@ class Foo { new Foo({ container: '.my-element' }); ``` + You can find an example of the above in this [class][container-class-example]; [container-class-example]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/mini_pipeline_graph_dropdown.js diff --git a/doc/development/fe_guide/droplab/droplab.md b/doc/development/fe_guide/droplab/droplab.md index 2f8c79abde1..1c6d895b3ab 100644 --- a/doc/development/fe_guide/droplab/droplab.md +++ b/doc/development/fe_guide/droplab/droplab.md @@ -25,6 +25,7 @@ If you do not provide any arguments, it will globally query and instantiate all <!-- ... --> <ul> ``` + ```js const droplab = new DropLab(); droplab.init(); @@ -45,6 +46,7 @@ You can add static list items. <li>Static value 2</li> <ul> ``` + ```js const droplab = new DropLab(); droplab.init(); @@ -62,6 +64,7 @@ a non-global instance of DropLab using the `DropLab.prototype.init` method. <!-- ... --> <ul> ``` + ```js const trigger = document.getElementById('trigger'); const list = document.getElementById('list'); @@ -79,6 +82,7 @@ You can also add hooks to an existing DropLab instance using `DropLab.prototype. <a href="#" id="trigger" data-dropdown-trigger="#list">Toggle</a> <ul id="list" data-dropdown><!-- ... --><ul> ``` + ```js const droplab = new DropLab(); @@ -109,6 +113,7 @@ for all `data-dynamic` dropdown lists tracked by that DropLab instance. <li><a href="#" data-id="{{id}}">{{text}}</a></li> </ul> ``` + ```js const droplab = new DropLab(); @@ -131,6 +136,7 @@ the data as the second argument and the `id` of the trigger element as the first <li><a href="#" data-id="{{id}}">{{text}}</a></li> </ul> ``` + ```js const droplab = new DropLab(); @@ -160,6 +166,7 @@ dropdown lists, one of which is dynamic. </ul> </div> ``` + ```js const droplab = new DropLab(); @@ -216,6 +223,7 @@ Some plugins require configuration values, the config object can be passed as th <a href="#" id="trigger" data-dropdown-trigger="#list">Toggle</a> <ul id="list" data-dropdown><!-- ... --><ul> ``` + ```js const droplab = new DropLab(); diff --git a/doc/development/fe_guide/droplab/plugins/ajax.md b/doc/development/fe_guide/droplab/plugins/ajax.md index b6a883ce6c4..4b76b207d88 100644 --- a/doc/development/fe_guide/droplab/plugins/ajax.md +++ b/doc/development/fe_guide/droplab/plugins/ajax.md @@ -17,18 +17,19 @@ Add the `Ajax` object to the plugins array of a `DropLab.prototype.init` or `Dro <a href="#" id="trigger" data-dropdown-trigger="#list">Toggle</a> <ul id="list" data-dropdown><!-- ... --><ul> ``` + ```js - const droplab = new DropLab(); +const droplab = new DropLab(); - const trigger = document.getElementById('trigger'); - const list = document.getElementById('list'); +const trigger = document.getElementById('trigger'); +const list = document.getElementById('list'); - droplab.addHook(trigger, list, [Ajax], { - Ajax: { - endpoint: '/some-endpoint', - method: 'setData', - }, - }); +droplab.addHook(trigger, list, [Ajax], { + Ajax: { + endpoint: '/some-endpoint', + method: 'setData', + }, +}); ``` Optionally you can set `loadingTemplate` to a HTML string. This HTML string will diff --git a/doc/development/fe_guide/droplab/plugins/filter.md b/doc/development/fe_guide/droplab/plugins/filter.md index 1f188c64fe4..b867394a241 100644 --- a/doc/development/fe_guide/droplab/plugins/filter.md +++ b/doc/development/fe_guide/droplab/plugins/filter.md @@ -17,25 +17,26 @@ Add the `Filter` object to the plugins array of a `DropLab.prototype.init` or `D <li><a href="#" data-id="{{id}}">{{text}}</a></li> <ul> ``` + ```js - const droplab = new DropLab(); - - const trigger = document.getElementById('trigger'); - const list = document.getElementById('list'); - - droplab.init(trigger, list, [Filter], { - Filter: { - template: 'text', - }, - }); - - droplab.addData('trigger', [{ - id: 0, - text: 'Jacob', - }, { - id: 1, - text: 'Jeff', - }]); +const droplab = new DropLab(); + +const trigger = document.getElementById('trigger'); +const list = document.getElementById('list'); + +droplab.init(trigger, list, [Filter], { + Filter: { + template: 'text', + }, +}); + +droplab.addData('trigger', [{ + id: 0, + text: 'Jacob', +}, { + id: 1, + text: 'Jeff', +}]); ``` Above, the input string will be compared against the `test` key of the passed data objects. diff --git a/doc/development/fe_guide/droplab/plugins/input_setter.md b/doc/development/fe_guide/droplab/plugins/input_setter.md index e4050213869..db492da478a 100644 --- a/doc/development/fe_guide/droplab/plugins/input_setter.md +++ b/doc/development/fe_guide/droplab/plugins/input_setter.md @@ -22,33 +22,34 @@ You can also set the `InputSetter` config to an array of objects, which will all <li><a href="#" data-id="{{id}}">{{text}}</a></li> <ul> ``` + ```js - const droplab = new DropLab(); - - const trigger = document.getElementById('trigger'); - const list = document.getElementById('list'); - - const input = document.getElementById('input'); - const div = document.getElementById('div'); - - droplab.init(trigger, list, [InputSetter], { - InputSetter: [{ - input: input, - valueAttribute: 'data-id', - } { - input: div, - valueAttribute: 'data-id', - inputAttribute: 'data-selected-id', - }], - }); - - droplab.addData('trigger', [{ - id: 0, - text: 'Jacob', - }, { - id: 1, - text: 'Jeff', - }]); +const droplab = new DropLab(); + +const trigger = document.getElementById('trigger'); +const list = document.getElementById('list'); + +const input = document.getElementById('input'); +const div = document.getElementById('div'); + +droplab.init(trigger, list, [InputSetter], { + InputSetter: [{ + input: input, + valueAttribute: 'data-id', + } { + input: div, + valueAttribute: 'data-id', + inputAttribute: 'data-selected-id', + }], +}); + +droplab.addData('trigger', [{ + id: 0, + text: 'Jacob', +}, { + id: 1, + text: 'Jeff', +}]); ``` Above, if the second list item was clicked, it would update the `#input` element diff --git a/doc/development/fe_guide/emojis.md b/doc/development/fe_guide/emojis.md index 38794c47965..6d324d4c4a0 100644 --- a/doc/development/fe_guide/emojis.md +++ b/doc/development/fe_guide/emojis.md @@ -3,10 +3,10 @@ GitLab supports native unicode emojis and fallsback to image-based emojis selectively when your platform does not support it. -# How to update Emojis +## How to update Emojis 1. Update the `gemojione` gem - 1. Update `fixtures/emojis/index.json` from [Gemojione](https://github.com/jonathanwiesel/gemojione/blob/master/config/index.json). + 1. Update `fixtures/emojis/index.json` from [Gemojione](https://github.com/bonusly/gemojione/blob/master/config/index.json). In the future, we could grab the file directly from the gem. We should probably make a PR on the Gemojione project to get access to all emojis after being parsed or just a raw path to the `json` file itself. diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md index 9fcd32fddfa..55b719227e5 100644 --- a/doc/development/fe_guide/graphql.md +++ b/doc/development/fe_guide/graphql.md @@ -55,7 +55,6 @@ It is possible to manage an application state with Apollo by passing in a resolvers object when creating the default client. The default state can be set by writing to the cache after setting up the default client. - ```javascript import Vue from 'vue'; import VueApollo from 'vue-apollo'; @@ -115,13 +114,12 @@ defaultClient.query(query) .then(result => console.log(result)); ``` -Read more about the [Apollo] client in the [Apollo documentation][apollo-client-docs]. +Read more about the [Apollo] client in the [Apollo documentation](https://www.apollographql.com/docs/tutorial/client/). [Apollo]: https://www.apollographql.com/ [vue-apollo]: https://github.com/Akryum/vue-apollo/ [vue-apollo-docs]: https://akryum.github.io/vue-apollo/ [feature-flags]: ../feature_flags.md [default-client]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/lib/graphql.js -[apollo-client-docs]: https://www.apollographql.com/docs/tutorial/client.html [vue-test-utils]: https://vue-test-utils.vuejs.org/ [apollo-link-state]: https://www.apollographql.com/docs/link/links/state.html diff --git a/doc/development/fe_guide/security.md b/doc/development/fe_guide/security.md index 83bb449e54d..47ac87fc895 100644 --- a/doc/development/fe_guide/security.md +++ b/doc/development/fe_guide/security.md @@ -1,5 +1,6 @@ # Security -### Resources + +## Resources [Mozilla’s HTTP Observatory CLI][observatory-cli] and the [Qualys SSL Labs Server Test][qualys-ssl] are good resources for finding @@ -56,7 +57,7 @@ Some resources on implementing Subresource Integrity: --> -### Including external resources +## Including external resources External fonts, CSS, and JavaScript should never be used with the exception of Google Analytics and Piwik - and only when the instance has enabled it. Assets @@ -64,7 +65,7 @@ should always be hosted and served locally from the GitLab instance. Embedded resources via `iframes` should never be used except in certain circumstances such as with ReCaptcha, which cannot be used without an `iframe`. -### Avoiding inline scripts and styles +## Avoiding inline scripts and styles In order to protect users from [XSS vulnerabilities][xss], we will disable inline scripts in the future using Content Security Policy. diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md index 6c7572352ec..421b7265613 100644 --- a/doc/development/fe_guide/vue.md +++ b/doc/development/fe_guide/vue.md @@ -34,6 +34,7 @@ new_feature │ └── new_feature_store.js ├── index.js ``` + _For consistency purposes, we recommend you to follow the same structure._ Let's look into each of them: diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md index c67467b7c11..739f4207e27 100644 --- a/doc/development/feature_flags/controls.md +++ b/doc/development/feature_flags/controls.md @@ -5,7 +5,7 @@ GitLab Inc. provided environments such as staging and production, you need to have access to the chatops bot. Chatops bot is currently running on the ops instance, which is different from GitLab.com or dev.gitlab.org. -Follow the Chatops document to [request access](https://docs.gitlab.com/ee/development/chatops_on_gitlabcom.html#requesting-access). +Follow the Chatops document to [request access](../chatops_on_gitlabcom.md#requesting-access). Once you are added to the project test if your access propagated, run: @@ -112,7 +112,7 @@ instances. Make sure to add the ~"feature flag" label to this merge request so release managers are aware the changes are hidden behind a feature flag. If the merge request has to be picked into a stable branch, make sure to also add the appropriate "Pick into X" label (e.g. "Pick into XX.X"). -See [the process document](https://docs.gitlab.com/ee/development/feature_flags/process.html#including-a-feature-behind-feature-flag-in-the-final-release) for further details. +See [the process document](process.md#including-a-feature-behind-feature-flag-in-the-final-release) for further details. When a feature gate has been removed from the code base, the value still exists in the database. diff --git a/doc/development/feature_flags/development.md b/doc/development/feature_flags/development.md index 238052529d9..98773026122 100644 --- a/doc/development/feature_flags/development.md +++ b/doc/development/feature_flags/development.md @@ -57,7 +57,7 @@ the feature flag check will default to `true`. As an example, if you were to ship the backend half of a feature behind a flag, you'd want to explicitly disable that flag until the frontend half is also ready -to be shipped. [You can do this via Chatops](https://docs.gitlab.com/ee/development/feature_flags/controls.html): +to be shipped. [You can do this via Chatops](controls.md): ``` /chatops run feature set some_feature 0 diff --git a/doc/development/geo.md b/doc/development/geo.md index a10f13b069f..685d4e44ad3 100644 --- a/doc/development/geo.md +++ b/doc/development/geo.md @@ -1,4 +1,4 @@ -# Geo (development) **[PREMIUM ONLY]** +# Geo (development) **(PREMIUM ONLY)** Geo connects GitLab instances together. One GitLab instance is designated as a **primary** node and can be run with multiple diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md index 5552d5d37b4..2ade59b76ed 100644 --- a/doc/development/gitaly.md +++ b/doc/development/gitaly.md @@ -237,24 +237,23 @@ Here are the steps to gate a new feature in Gitaly behind a feature flag. 1. Create prometheus metrics: ```go - var findAllTagsRequests = prometheus.NewCounterVec( - prometheus.CounterOpts{ - Name: "gitaly_find_all_tags_requests_total", - Help: "Counter of go vs ruby implementation of FindAllTags", - }, - []string{"implementation"}, - ) + var findAllTagsRequests = prometheus.NewCounterVec( + prometheus.CounterOpts{ + Name: "gitaly_find_all_tags_requests_total", + Help: "Counter of go vs ruby implementation of FindAllTags", + }, + []string{"implementation"}, ) func init() { - prometheus.Register(findAllTagsRequests) + prometheus.Register(findAllTagsRequests) } if featureflag.IsEnabled(ctx, findAllTagsFeatureFlag) { - findAllTagsRequests.WithLabelValues("go").Inc() + findAllTagsRequests.WithLabelValues("go").Inc() // go implementation } else { - findAllTagsRequests.WithLabelValues("ruby").Inc() + findAllTagsRequests.WithLabelValues("ruby").Inc() // ruby implementation } ``` diff --git a/doc/development/go_guide/index.md b/doc/development/go_guide/index.md index f961a2fc837..f09339eb3a4 100644 --- a/doc/development/go_guide/index.md +++ b/doc/development/go_guide/index.md @@ -41,7 +41,7 @@ of possible security breaches in our code: Remember to run [SAST](../../user/application_security/sast/index.md) -**[ULTIMATE]** on your project (or at least the [gosec +**(ULTIMATE)** on your project (or at least the [gosec analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/gosec)), and to follow our [Security requirements](../code_review.md#security-requirements). @@ -95,9 +95,9 @@ Dependencies should be kept to the minimum. The introduction of a new dependency should be argued in the merge request, as per our [Approval Guidelines](../code_review.md#approval-guidelines). Both [License Management](../../user/project/merge_requests/license_management.md) -**[ULTIMATE]** and [Dependency +**(ULTIMATE)** and [Dependency Scanning](../../user/application_security/dependency_scanning/index.md) -**[ULTIMATE]** should be activated on all projects to ensure new dependencies +**(ULTIMATE)** should be activated on all projects to ensure new dependencies security status and license compatibility. ### Modules diff --git a/doc/development/gotchas.md b/doc/development/gotchas.md index 1b9ebb50c29..13dda17bb7d 100644 --- a/doc/development/gotchas.md +++ b/doc/development/gotchas.md @@ -101,10 +101,10 @@ end in a prepended module, which is very likely the case in EE. We could see error like this: - ``` - 1.1) Failure/Error: expect_any_instance_of(ApplicationSetting).to receive_messages(messages) - Using `any_instance` to stub a method (elasticsearch_indexing) that has been defined on a prepended module (EE::ApplicationSetting) is not supported. - ``` + ``` + 1.1) Failure/Error: expect_any_instance_of(ApplicationSetting).to receive_messages(messages) + Using `any_instance` to stub a method (elasticsearch_indexing) that has been defined on a prepended module (EE::ApplicationSetting) is not supported. + ``` ### Alternative: `expect_next_instance_of` diff --git a/doc/development/i18n/proofreader.md b/doc/development/i18n/proofreader.md index 35c5b155594..910d7296057 100644 --- a/doc/development/i18n/proofreader.md +++ b/doc/development/i18n/proofreader.md @@ -106,32 +106,31 @@ are very appreciative of the work done by translators and proofreaders! 1. Contribute translations to GitLab. See instructions for [translating GitLab](translation.md). - Translating GitLab is a community effort that requires team work and - attention to detail. Proofreaders play an important role helping new - contributors, and ensuring the consistency and quality of translations. - Your conduct and contributions as a translator should reflect this before - requesting to be a proofreader. + Translating GitLab is a community effort that requires team work and + attention to detail. Proofreaders play an important role helping new + contributors, and ensuring the consistency and quality of translations. + Your conduct and contributions as a translator should reflect this before + requesting to be a proofreader. 1. Request proofreader permissions by opening a merge request to add yourself to the list of proofreaders. - Open the [proofreader.md source file][proofreader-src] and click **Edit**. + Open the [proofreader.md source file][proofreader-src] and click **Edit**. - Add your language in alphabetical order, and add yourself to the list - including: - - name - - link to your GitLab profile - - link to your CrowdIn profile + Add your language in alphabetical order, and add yourself to the list + including: + - name + - link to your GitLab profile + - link to your CrowdIn profile - In the merge request description, please include links to any projects you - have previously translated. + In the merge request description, please include links to any projects you + have previously translated. 1. Your request to become a proofreader will be considered on the merits of your previous translations by [GitLab team members](https://about.gitlab.com/team/) or [Core team members](https://about.gitlab.com/core-team/) who are fluent in the language or current proofreaders. - When a request is made for the first proofreader for a language and there are no [GitLab team members](https://about.gitlab.com/team/) - or [Core team members](https://about.gitlab.com/core-team/) who speak the language, we will request links to previous translation work in other communities or projects. - + or [Core team members](https://about.gitlab.com/core-team/) who speak the language, we will request links to previous translation work in other communities or projects. [proofreader-src]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/i18n/proofreader.md diff --git a/doc/development/integrations/jira_connect.md b/doc/development/integrations/jira_connect.md index 5bf43d320c6..e1350b02262 100644 --- a/doc/development/integrations/jira_connect.md +++ b/doc/development/integrations/jira_connect.md @@ -4,7 +4,7 @@ The following are required to install and test the app: 1. A Jira Cloud instance - Atlassian provides free instances for development and testing. [Click here to sign up](http://go.atlassian.com/cloud-dev). + Atlassian provides free instances for development and testing. [Click here to sign up](https://developer.atlassian.com/platform/marketplace/getting-started/#free-developer-instances-to-build-and-test-your-app). 1. A GitLab instance available over the internet @@ -15,7 +15,7 @@ The following are required to install and test the app: > This feature is currently behind the `:jira_connect_app` feature flag -# Installing the app in Jira +## Installing the app in Jira 1. Enable Jira development mode to install apps that are not from the Atlassian Marketplace @@ -30,9 +30,11 @@ The following are required to install and test the app: 1. In the **From this URL** field, provide a link to the app descriptor. The host and port must point to your GitLab instance. For example: + ``` https://xxxx.serveo.net/-/jira_connect/app_descriptor.json ``` + 1. Click **Upload**. If the install was successful, you should see the **GitLab for Jira** app under **Manage apps**. diff --git a/doc/development/licensed_feature_availability.md b/doc/development/licensed_feature_availability.md index 6f3dd59b2c3..80ec7b8c0cf 100644 --- a/doc/development/licensed_feature_availability.md +++ b/doc/development/licensed_feature_availability.md @@ -1,18 +1,18 @@ -# Licensed feature availability **[STARTER]** +# Licensed feature availability **(STARTER)** -As of GitLab 9.4, we've been supporting a simplified version of licensed -feature availability checks via `ee/app/models/license.rb`, both for +As of GitLab 9.4, we've been supporting a simplified version of licensed +feature availability checks via `ee/app/models/license.rb`, both for on-premise or GitLab.com plans and features. ## Restricting features scoped by namespaces or projects GitLab.com plans are persisted on user groups and namespaces, therefore, if you're adding a -feature such as [Related issues](../user/project/issues/related_issues.md) or -[Service desk](../user/project/service_desk.md), +feature such as [Related issues](../user/project/issues/related_issues.md) or +[Service desk](../user/project/service_desk.md), it should be restricted on namespace scope. -1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in - `ee/app/models/license.rb`. Note on `ee/app/models/ee/namespace.rb` that _Bronze_ GitLab.com +1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in + `ee/app/models/license.rb`. Note on `ee/app/models/ee/namespace.rb` that _Bronze_ GitLab.com features maps to on-premise _EES_, _Silver_ to _EEP_ and _Gold_ to _EEU_. 2. Check using: @@ -22,12 +22,12 @@ project.feature_available?(:feature_symbol) ## Restricting global features (instance) -However, for features such as [Geo](../administration/geo/replication/index.md) and -[Load balancing](../administration/database_load_balancing.md), which cannot be restricted -to only a subset of projects or namespaces, the check will be made directly in +However, for features such as [Geo](../administration/geo/replication/index.md) and +[Load balancing](../administration/database_load_balancing.md), which cannot be restricted +to only a subset of projects or namespaces, the check will be made directly in the instance license. -1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in +1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in `ee/app/models/license.rb`. 2. Add the same feature symbol to `GLOBAL_FEATURES` 3. Check using: diff --git a/doc/development/logging.md b/doc/development/logging.md index d61441813b2..4f63c84fc0e 100644 --- a/doc/development/logging.md +++ b/doc/development/logging.md @@ -30,8 +30,8 @@ Completed 200 OK in 166ms (Views: 117.4ms | ActiveRecord: 27.2ms) These logs suffer from a number of problems: 1. They often lack timestamps or other contextual information (e.g. project ID, user) -2. They may span multiple lines, which make them hard to find via Elasticsearch. -3. They lack a common structure, which make them hard to parse by log +1. They may span multiple lines, which make them hard to find via Elasticsearch. +1. They lack a common structure, which make them hard to parse by log forwarders, such as Logstash or Fluentd. This also makes them hard to search. @@ -67,46 +67,46 @@ importer progresses. Here's what to do: make it easy for people to search pertinent logs in one place. For example, `geo.log` contains all logs pertaining to GitLab Geo. To create a new file: - 1. Choose a filename (e.g. `importer_json.log`). - 1. Create a new subclass of `Gitlab::JsonLogger`: - - ```ruby - module Gitlab - module Import - class Logger < ::Gitlab::JsonLogger - def self.file_name_noext - 'importer' - end + 1. Choose a filename (e.g. `importer_json.log`). + 1. Create a new subclass of `Gitlab::JsonLogger`: + + ```ruby + module Gitlab + module Import + class Logger < ::Gitlab::JsonLogger + def self.file_name_noext + 'importer' end - end - end - ``` + end + end + end + ``` - 1. In your class where you want to log, you might initialize the logger as an instance variable: + 1. In your class where you want to log, you might initialize the logger as an instance variable: - ```ruby - attr_accessor :logger + ```ruby + attr_accessor :logger - def initialize - @logger = Gitlab::Import::Logger.build - end - ``` + def initialize + @logger = Gitlab::Import::Logger.build + end + ``` - Note that it's useful to memoize this because creating a new logger - each time you log will open a file, adding unnecessary overhead. + Note that it's useful to memoize this because creating a new logger + each time you log will open a file, adding unnecessary overhead. 1. Now insert log messages into your code. When adding logs, make sure to include all the context as key-value pairs: - ```ruby - # BAD - logger.info("Unable to create project #{project.id}") - ``` + ```ruby + # BAD + logger.info("Unable to create project #{project.id}") + ``` - ```ruby - # GOOD - logger.info(message: "Unable to create project", project_id: project.id) - ``` + ```ruby + # GOOD + logger.info(message: "Unable to create project", project_id: project.id) + ``` 1. Be sure to create a common base structure of your log messages. For example, all messages might have `current_user_id` and `project_id` to make it easier @@ -116,16 +116,16 @@ importer progresses. Here's what to do: logs properly if you [mix integer and string types](https://www.elastic.co/guide/en/elasticsearch/guide/current/mapping.html#_avoiding_type_gotchas): - ```ruby - # BAD - logger.info(message: "Import error", error: 1) - logger.info(message: "Import error", error: "I/O failure") - ``` + ```ruby + # BAD + logger.info(message: "Import error", error: 1) + logger.info(message: "Import error", error: "I/O failure") + ``` - ```ruby - # GOOD - logger.info(message: "Import error", error_code: 1, error: "I/O failure") - ``` + ```ruby + # GOOD + logger.info(message: "Import error", error_code: 1, error: "I/O failure") + ``` ## Additional steps with new log files diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md index 9b26f691b55..0c7601b415e 100644 --- a/doc/development/migration_style_guide.md +++ b/doc/development/migration_style_guide.md @@ -21,7 +21,7 @@ When downtime is necessary the migration has to be approved by: 1. A Database Specialist An up-to-date list of people holding these titles can be found at -<https://about.gitlab.com/team/>. +<https://about.gitlab.com/company/team/>. When writing your migrations, also consider that databases might have stale data or inconsistencies and guard for that. Try to make as few assumptions as diff --git a/doc/development/new_fe_guide/development/components.md b/doc/development/new_fe_guide/development/components.md index 963ce53423b..cebdc87eab9 100644 --- a/doc/development/new_fe_guide/development/components.md +++ b/doc/development/new_fe_guide/development/components.md @@ -13,7 +13,7 @@ D3 is very popular across many projects outside of GitLab: - [The New York Times](https://archive.nytimes.com/www.nytimes.com/interactive/2012/02/13/us/politics/2013-budget-proposal-graphic.html) - [plot.ly](https://plot.ly/) -- [Droptask](https://www.droptask.com/) +- [Droptask](https://www.ayoa.com/previously-droptask/) Within GitLab, D3 has been used for the following notable features diff --git a/doc/development/new_fe_guide/development/performance.md b/doc/development/new_fe_guide/development/performance.md index 640a8d64176..c54b8305991 100644 --- a/doc/development/new_fe_guide/development/performance.md +++ b/doc/development/new_fe_guide/development/performance.md @@ -2,10 +2,10 @@ ## Monitoring -We have a performance dashboard available in one of our [grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://sitespeed.io) every 6 hours. These changes are displayed after a set number of pages are aggregated. +We have a performance dashboard available in one of our [grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated. These pages can be found inside a text file in the gitlab-build-images [repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [gitlab.txt](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt) -Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing urls of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/team) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes will go live on the next scheduled run after the changes are merged into `master`. +Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing urls of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/company/team) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes will go live on the next scheduled run after the changes are merged into `master`. There are 3 recommended high impact metrics to review on each page: diff --git a/doc/development/new_fe_guide/development/testing.md b/doc/development/new_fe_guide/development/testing.md index 8441089418e..2b62c2a41fe 100644 --- a/doc/development/new_fe_guide/development/testing.md +++ b/doc/development/new_fe_guide/development/testing.md @@ -261,7 +261,7 @@ scenario 'successfully', :js do end ``` -The steps of each test are written using capybara methods ([documentation](http://www.rubydoc.info/gems/capybara/2.15.1)). +The steps of each test are written using capybara methods ([documentation](https://www.rubydoc.info/gems/capybara/2.15.1)). Bear in mind <abbr title="XMLHttpRequest">XHR</abbr> calls might require you to use `wait_for_requests` in between steps, like so: @@ -277,7 +277,7 @@ expect(page).not_to have_selector('.card') ### Vuex Helper: `testAction` -We have a helper available to make testing actions easier, as per [official documentation](https://vuex.vuejs.org/en/testing.html): +We have a helper available to make testing actions easier, as per [official documentation](https://vuex.vuejs.org/guide/testing.html): ``` testAction( diff --git a/doc/development/new_fe_guide/style/html.md b/doc/development/new_fe_guide/style/html.md index e8c9c2ccebf..1445da3f0e1 100644 --- a/doc/development/new_fe_guide/style/html.md +++ b/doc/development/new_fe_guide/style/html.md @@ -16,7 +16,7 @@ Button tags requires a `type` attribute according to the [W3C HTML specification ### Button role -If an HTML element has an `onClick` handler but is not a button, it should have `role="button"`. This is [more accessible](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_button_role). +If an HTML element has an `onClick` handler but is not a button, it should have `role="button"`. This is [more accessible](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role). ```html // bad diff --git a/doc/development/new_fe_guide/style/prettier.md b/doc/development/new_fe_guide/style/prettier.md index 4495f38f262..5f44c640d76 100644 --- a/doc/development/new_fe_guide/style/prettier.md +++ b/doc/development/new_fe_guide/style/prettier.md @@ -4,7 +4,7 @@ Our code is automatically formatted with [Prettier](https://prettier.io) to foll ## Editor -The easiest way to include prettier in your workflow is by setting up your preferred editor (all major editors are supported) accordingly. We suggest setting up prettier to run automatically when each file is saved. Find [here](https://prettier.io/docs/en/editors.html) the best way to set it up in your preferred editor. +The easiest way to include prettier in your workflow is by setting up your preferred editor (all major editors are supported) accordingly. We suggest setting up prettier to run automatically when each file is saved. Find [here](https://prettier.io/docs/en/editors.html) the best way to set it up in your preferred editor. Please take care that you only let Prettier format the same file types as the global Yarn script does (.js, .vue, and .scss). In VSCode by example you can easily exclude file formats in your settings file: @@ -28,6 +28,7 @@ Updates all currently staged files (based on `git diff`) with Prettier and saves ``` yarn prettier-staged ``` + Checks all currently staged files (based on `git diff`) with Prettier and log which files would need manual updating to the console. ``` diff --git a/doc/development/newlines_styleguide.md b/doc/development/newlines_styleguide.md index 5f7210020b6..a13adc2f13e 100644 --- a/doc/development/newlines_styleguide.md +++ b/doc/development/newlines_styleguide.md @@ -11,7 +11,7 @@ def method issue.save - render json: issue + render json: issue end ``` @@ -21,7 +21,7 @@ def method issue = Issue.new issue.save - render json: issue + render json: issue end ``` diff --git a/doc/development/packages.md b/doc/development/packages.md index ab0c5f9904d..08aa0b08525 100644 --- a/doc/development/packages.md +++ b/doc/development/packages.md @@ -1,15 +1,15 @@ -# Packages **[PREMIUM]** +# Packages **(PREMIUM)** This document will guide you through adding another [package management system](../administration/packages.md) support to GitLab. See already supported package types in [Packages documentation](../administration/packages.md) Since GitLab packages' UI is pretty generic, it is possible to add new -package system support by solely backend changes. This guide is superficial and does -not cover the way the code should be written. However, you can find a good example -by looking at existing merge requests with Maven and NPM support: +package system support by solely backend changes. This guide is superficial and does +not cover the way the code should be written. However, you can find a good example +by looking at existing merge requests with Maven and NPM support: -- [NPM registry support](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8673). +- [NPM registry support](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8673). - [Maven repository](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6607). - [Instance level endpoint for Maven repository](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8757) @@ -17,44 +17,44 @@ by looking at existing merge requests with Maven and NPM support: The existing database model requires the following: -- Every package belongs to a project. +- Every package belongs to a project. - Every package file belongs to a package. - A package can have one or more package files. - The package model is based on storing information about the package and its version. ## API endpoints -Package systems work with GitLab via API. For example `ee/lib/api/npm_packages.rb` -implements API endpoints to work with NPM clients. So, the first thing to do is to -add a new `ee/lib/api/your_name_packages.rb` file with API endpoints that are -necessary to make the package system client to work. Usually that means having -endpoints like: +Package systems work with GitLab via API. For example `ee/lib/api/npm_packages.rb` +implements API endpoints to work with NPM clients. So, the first thing to do is to +add a new `ee/lib/api/your_name_packages.rb` file with API endpoints that are +necessary to make the package system client to work. Usually that means having +endpoints like: - GET package information. - GET package file content. - PUT upload package. Since the packages belong to a project, it's expected to have project-level endpoint -for uploading and downloading them. For example: +for uploading and downloading them. For example: ``` GET https://gitlab.com/api/v4/projects/<your_project_id>/packages/npm/ PUT https://gitlab.com/api/v4/projects/<your_project_id>/packages/npm/ ``` -Group-level and instance-level endpoints are good to have but are optional. +Group-level and instance-level endpoints are good to have but are optional. NOTE: **Note:** -To avoid name conflict for instance-level endpoints we use +To avoid name conflict for instance-level endpoints we use [the package naming convention](../user/project/packages/npm_registry.md#package-naming-convention) ## Configuration -GitLab has a `packages` section in its configuration file (`gitlab.rb`). -It applies to all package systems supported by GitLab. Usually you don't need -to add anything there. +GitLab has a `packages` section in its configuration file (`gitlab.rb`). +It applies to all package systems supported by GitLab. Usually you don't need +to add anything there. -Packages can be configured to use object storage, therefore your code must support it. +Packages can be configured to use object storage, therefore your code must support it. ## Database @@ -63,6 +63,6 @@ Every time you upload a new package, you can either create a new record of `Pack or add files to existing record. `PackageFile` should be able to store all file-related information like the file `name`, `side`, `sha1`, etc. -If there is specific data necessary to be stored for only one package system support, -consider creating a separate metadata model. See `packages_maven_metadata` table +If there is specific data necessary to be stored for only one package system support, +consider creating a separate metadata model. See `packages_maven_metadata` table and `Packages::MavenMetadatum` model as example for package specific data. diff --git a/doc/development/performance.md b/doc/development/performance.md index c034f4a344b..8b569a677b6 100644 --- a/doc/development/performance.md +++ b/doc/development/performance.md @@ -246,6 +246,7 @@ irb(main):002:0> results.last.attributes.keys irb(main):003:0> results.where(status: "passed").average(:time).to_s => "0.211340155844156" ``` + These results can also be placed into a PostgreSQL database by setting the `RSPEC_PROFILING_POSTGRES_URL` variable. This is used to profile the test suite when running in the CI environment. diff --git a/doc/development/profiling.md b/doc/development/profiling.md index 795523b82aa..e1d1d2e33fa 100644 --- a/doc/development/profiling.md +++ b/doc/development/profiling.md @@ -95,7 +95,9 @@ Sherlock is a custom profiling tool built into GitLab. Sherlock is _only_ available when running GitLab in development mode _and_ when setting the environment variable `ENABLE_SHERLOCK` to a non empty value. For example: - ENABLE_SHERLOCK=1 bundle exec rails s +```sh +ENABLE_SHERLOCK=1 bundle exec rails s +``` Recorded transactions can be found by navigating to `/sherlock/transactions`. @@ -106,7 +108,9 @@ Bullet adds quite a bit of logging noise it's disabled by default. To enable Bullet, set the environment variable `ENABLE_BULLET` to a non-empty value before starting GitLab. For example: - ENABLE_BULLET=true bundle exec rails s +```sh +ENABLE_BULLET=true bundle exec rails s +``` Bullet will log query problems to both the Rails log as well as the Chrome console. diff --git a/doc/development/prometheus_metrics.md b/doc/development/prometheus_metrics.md index 0511e735843..576601372a3 100644 --- a/doc/development/prometheus_metrics.md +++ b/doc/development/prometheus_metrics.md @@ -33,12 +33,10 @@ For example: you might be interested in migrating all dependent data to a differ class ImportCommonMetrics < ActiveRecord::Migration[4.2] include Gitlab::Database::MigrationHelpers - require Rails.root.join('db/importers/common_metrics_importer.rb') - DOWNTIME = false def up - Importers::CommonMetricsImporter.new.execute + ::Gitlab::DatabaseImporters::CommonMetrics::Importer.new.execute end def down diff --git a/doc/development/python_guide/index.md b/doc/development/python_guide/index.md index 6025dc9ebf2..a80bee27d4a 100644 --- a/doc/development/python_guide/index.md +++ b/doc/development/python_guide/index.md @@ -36,7 +36,7 @@ You can read more about it in: <https://github.com/pyenv/pyenv-installer#prerequ Pyenv installation will add required changes to Bash. If you use a different shell, check for any additional steps required for it. -For Fish, you can install a plugin for [Fisherman](https://github.com/fisherman/fisherman): +For Fish, you can install a plugin for [Fisher](https://github.com/jorgebucaran/fisher): ```bash fisher add fisherman/pyenv @@ -76,4 +76,3 @@ pipenv shell After running that command, you can run GitLab on the same shell and it will be using the Python and dependencies installed from the `pipenv install` command. - diff --git a/doc/development/query_recorder.md b/doc/development/query_recorder.md index 2167ed57428..a6b60149ea4 100644 --- a/doc/development/query_recorder.md +++ b/doc/development/query_recorder.md @@ -1,6 +1,6 @@ # QueryRecorder -QueryRecorder is a tool for detecting the [N+1 queries problem](http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations) from tests. +QueryRecorder is a tool for detecting the [N+1 queries problem](https://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations) from tests. > Implemented in [spec/support/query_recorder.rb](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/spec/support/helpers/query_recorder.rb) via [9c623e3e](https://gitlab.com/gitlab-org/gitlab-ce/commit/9c623e3e5d7434f2e30f7c389d13e5af4ede770a) @@ -86,4 +86,4 @@ QueryRecorder SQL: SELECT COUNT(*) FROM "issues" WHERE "issues"."deleted_at" IS - [Bullet](profiling.md#Bullet) For finding `N+1` query problems - [Performance guidelines](performance.md) -- [Merge request performance guidelines](merge_request_performance_guidelines.md#query-counts)
\ No newline at end of file +- [Merge request performance guidelines](merge_request_performance_guidelines.md#query-counts) diff --git a/doc/development/rake_tasks.md b/doc/development/rake_tasks.md index 4fc10b6af5c..c97e179910b 100644 --- a/doc/development/rake_tasks.md +++ b/doc/development/rake_tasks.md @@ -28,7 +28,7 @@ bin/rake "gitlab:seed:issues[group-path/project-path]" By default, this seeds an average of 2 issues per week for the last 5 weeks per project. -#### Seeding issues for Insights charts **[ULTIMATE]** +#### Seeding issues for Insights charts **(ULTIMATE)** You can seed issues specifically for working with the [Insights charts](../user/group/insights/index.md) with the diff --git a/doc/development/routing.md b/doc/development/routing.md index e9c0ad8d4e8..a25eb48b73c 100644 --- a/doc/development/routing.md +++ b/doc/development/routing.md @@ -7,11 +7,15 @@ support subgroups, GitLab project and group routes use the wildcard character to match project and group routes. For example, we might have a path such as: - /gitlab-com/customer-success/north-america/west/customerA +``` +/gitlab-com/customer-success/north-america/west/customerA +``` However, paths can be ambiguous. Consider the following example: - /gitlab-com/edit +``` +/gitlab-com/edit +``` It's ambiguous whether there is a subgroup named `edit` or whether this is a special endpoint to edit the `gitlab-com` group. @@ -25,8 +29,10 @@ number of [reserved names](../user/reserved_names.md). We have a number of global routes. For example: - /-/health - /-/metrics +``` +/-/health +/-/metrics +``` ## Group routes @@ -34,10 +40,12 @@ Every group route must be under the `/-/` scope. Examples: - gitlab-org/-/edit - gitlab-org/-/activity - gitlab-org/-/security/dashboard - gitlab-org/serverless/-/activity +``` +gitlab-org/-/edit +gitlab-org/-/activity +gitlab-org/-/security/dashboard +gitlab-org/serverless/-/activity +``` To achieve that, use the `scope '-'` method. @@ -48,10 +56,12 @@ client or other software requires something different. Examples: - gitlab-org/gitlab-ce/-/activity - gitlab-org/gitlab-ce/-/jobs/123 - gitlab-org/gitlab-ce/-/settings/repository - gitlab-org/serverless/runtimes/-/settings/repository +``` +gitlab-org/gitlab-ce/-/activity +gitlab-org/gitlab-ce/-/jobs/123 +gitlab-org/gitlab-ce/-/settings/repository +gitlab-org/serverless/runtimes/-/settings/repository +``` Currently, only some project routes are placed under the `/-/` scope. However, you can help us migrate more of them! To migrate project routes: diff --git a/doc/development/sql.md b/doc/development/sql.md index edeca7fb298..a256fd46c09 100644 --- a/doc/development/sql.md +++ b/doc/development/sql.md @@ -94,7 +94,9 @@ on the amount of data indexed). To keep naming of these indexes consistent please use the following naming pattern: - index_TABLE_on_COLUMN_trigram +``` +index_TABLE_on_COLUMN_trigram +``` For example, a GIN/trigram index for `issues.title` would be called `index_issues_on_title_trigram`. diff --git a/doc/development/testing_guide/ci.md b/doc/development/testing_guide/ci.md index 7a7fca46534..87d48726268 100644 --- a/doc/development/testing_guide/ci.md +++ b/doc/development/testing_guide/ci.md @@ -1,6 +1,6 @@ # GitLab tests in the Continuous Integration (CI) context -### Test suite parallelization on the CI +## Test suite parallelization on the CI Our current CI parallelization setup is as follows: @@ -26,7 +26,7 @@ Our current CI parallelization setup is as follows: After that, the next pipeline will use the up-to-date `knapsack/${CI_PROJECT_NAME}/rspec_report-master.json` file. -### Monitoring +## Monitoring The GitLab test suite is [monitored] for the `master` branch, and any branch that includes `rspec-profile` in their name. diff --git a/doc/development/testing_guide/end_to_end/index.md b/doc/development/testing_guide/end_to_end/index.md index 59eb3ecfd7e..2dc06ba10a5 100644 --- a/doc/development/testing_guide/end_to_end/index.md +++ b/doc/development/testing_guide/end_to_end/index.md @@ -148,7 +148,7 @@ Once you decided where to put [test environment orchestration scenarios] and the [GitLab QA orchestrator README][gitlab-qa-readme], and [the already existing instance-level scenarios][instance-level scenarios]. -Continued reading: +Continued reading: - [Quick Start Guide](quick_start_guide.md) - [Style Guide](style_guide.md) diff --git a/doc/development/testing_guide/end_to_end/quick_start_guide.md b/doc/development/testing_guide/end_to_end/quick_start_guide.md index 041bdf716b3..efcfd44bc22 100644 --- a/doc/development/testing_guide/end_to_end/quick_start_guide.md +++ b/doc/development/testing_guide/end_to_end/quick_start_guide.md @@ -222,7 +222,7 @@ As the pre-conditions for our test suite, the things that needs to happen before - A project being created with an issue and labels already set; - The issue page being opened with only one scoped label applied to it. -> When running end-to-end tests as part of the GitLab's continuous integration process [a license is already set as an environment variable](https://gitlab.com/gitlab-org/gitlab-ee/blob/1a60d926740db10e3b5724713285780a4f470531/qa/qa/ee/strategy.rb#L20). For running tests locally you can set up such license by following the document [what tests can be run?](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/what_tests_can_be_run.md#supported-remote-grid-environment-variables), based on the [supported GitLab environment variables](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/what_tests_can_be_run.md#supported-gitlab-environment-variables). +> When running end-to-end tests as part of the GitLab's continuous integration process [a license is already set as an environment variable](https://gitlab.com/gitlab-org/gitlab-ee/blob/1a60d926740db10e3b5724713285780a4f470531/qa/qa/ee/strategy.rb#L20). For running tests locally you can set up such license by following the document [what tests can be run?](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/what_tests_can_be_run.md), based on the [supported GitLab environment variables](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/what_tests_can_be_run.md#supported-gitlab-environment-variables). #### Implementation @@ -394,15 +394,15 @@ end By defining the `api_get_path` method, we allow the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/qa/qa/resource/api_fabricator.rb) module to know which path to use to get a single issue. -> This `GET` path can be found in the [public API documentation](https://docs.gitlab.com/ee/api/issues.html#single-issue). +> This `GET` path can be found in the [public API documentation](../../../api/issues.md#single-issue). By defining the `api_post_path` method, we allow the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/qa/qa/resource/api_fabricator.rb) module to know which path to use to create a new issue in a specific project. -> This `POST` path can be found in the [public API documentation](https://docs.gitlab.com/ee/api/issues.html#new-issue). +> This `POST` path can be found in the [public API documentation](../../../api/issues.md#new-issue). By defining the `api_post_body` method, we allow the [`ApiFabricator.api_post`](https://gitlab.com/gitlab-org/gitlab-ee/blob/a9177ca1812bac57e2b2fa4560e1d5dd8ffac38b/qa/qa/resource/api_fabricator.rb#L68) method to know which data to send when making the `POST` request. -> Notice that we pass both `labels` and `title` attributes in the `api_post_body`, where `labels` receives an array of labels, and [`title` is required](https://docs.gitlab.com/ee/api/issues.html#new-issue). Also, notice that we keep them alphabetically organized. +> Notice that we pass both `labels` and `title` attributes in the `api_post_body`, where `labels` receives an array of labels, and [`title` is required](../../../api/issues.md#new-issue). Also, notice that we keep them alphabetically organized. **Label resource** @@ -441,7 +441,7 @@ By defining the `api_post_path` method, we allow for the [`ApiFabricator `](http By defining the `api_post_body` method, we we allow for the [`ApiFabricator.api_post`](https://gitlab.com/gitlab-org/gitlab-ee/blob/a9177ca1812bac57e2b2fa4560e1d5dd8ffac38b/qa/qa/resource/api_fabricator.rb#L68) method to know which data to send when making the `POST` request. -> Notice that we pass both `color` and `name` attributes in the `api_post_body` since [those are required](https://docs.gitlab.com/ee/api/labels.html#create-a-new-label). Also, notice that we keep them alphabetically organized. +> Notice that we pass both `color` and `name` attributes in the `api_post_body` since [those are required](../../../api/labels.md#create-a-new-label). Also, notice that we keep them alphabetically organized. ### 8. Page Objects diff --git a/doc/development/testing_guide/end_to_end/style_guide.md b/doc/development/testing_guide/end_to_end/style_guide.md index 0272e1810f2..52a8116e01c 100644 --- a/doc/development/testing_guide/end_to_end/style_guide.md +++ b/doc/development/testing_guide/end_to_end/style_guide.md @@ -63,17 +63,17 @@ We follow a simple formula roughly based on hungarian notation. - `_checkbox` - `_radio` - `_content` - + *Note: This list is a work in progress. This list will eventually be the end-all enumeration of all available types. I.e., any element that does not end with something in this list is bad form.* - + #### Examples **Good** ```ruby view '...' do - element :edit_button + element :edit_button element :notes_tab element :squash_checkbox element :username_field @@ -84,15 +84,15 @@ end **Bad** ```ruby -view '...' do +view '...' do # `_confirmation` should be `_field`. what sort of confirmation? a checkbox confirmation? no real way to disambiguate. # an appropriate replacement would be `element :password_confirmation_field` element :password_confirmation - # `clone_options` is too vague. If it's a dropdown menu, it should be `clone_dropdown`. + # `clone_options` is too vague. If it's a dropdown menu, it should be `clone_dropdown`. # If it's a checkbox, it should be `clone_checkbox` element :clone_options - + # how is this url being displayed? is it a textbox? a simple span? element :ssh_clone_url end diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md index 98df0b5ea7c..bb44cc595e9 100644 --- a/doc/development/testing_guide/frontend_testing.md +++ b/doc/development/testing_guide/frontend_testing.md @@ -501,17 +501,17 @@ The following are examples of tests that work for both Karma and Jest: it('makes a request', () => { const responseBody = getJSONFixture('some/fixture.json'); // loads spec/javascripts/fixtures/some/fixture.json axiosMock.onGet(endpoint).reply(200, responseBody); - + myButton.click(); - + // ... }); it('uses some HTML element', () => { loadFixtures('some/page.html'); // loads spec/javascripts/fixtures/some/page.html and adds it to the DOM - + const element = document.getElementById('#my-id'); - + // ... }); ``` diff --git a/doc/development/testing_guide/index.md b/doc/development/testing_guide/index.md index c4b18391cb2..aadbea1a540 100644 --- a/doc/development/testing_guide/index.md +++ b/doc/development/testing_guide/index.md @@ -11,7 +11,7 @@ importance. ## Overview -GitLab is built on top of [Ruby on Rails][rails], and we're using [RSpec] for all +GitLab is built on top of [Ruby on Rails](https://rubyonrails.org/), and we're using [RSpec] for all the backend tests, with [Capybara] for end-to-end integration testing. On the frontend side, we're using [Karma] and [Jasmine] for JavaScript unit and integration testing. @@ -80,7 +80,6 @@ Everything you should know about how to run end-to-end tests using [Return to Development documentation](../README.md) -[rails]: http://rubyonrails.org/ [RSpec]: https://github.com/rspec/rspec-rails#feature-specs [Capybara]: https://github.com/teamcapybara/capybara [Karma]: http://karma-runner.github.io/ diff --git a/doc/development/understanding_explain_plans.md b/doc/development/understanding_explain_plans.md index bfbb7be70e3..11aafd7b639 100644 --- a/doc/development/understanding_explain_plans.md +++ b/doc/development/understanding_explain_plans.md @@ -654,7 +654,6 @@ and related tools such as: - <https://explain.depesz.com/> - <http://tatiyants.com/postgres-query-plan-visualization/> - ## Producing query plans There are a few ways to get the output of a query plan. Of course you diff --git a/doc/development/ux_guide/resources.md b/doc/development/ux_guide/resources.md index baec235a8dd..ae092246d05 100644 --- a/doc/development/ux_guide/resources.md +++ b/doc/development/ux_guide/resources.md @@ -1,5 +1,5 @@ --- -redirect_to: 'https://design.gitlab.com/resources/design-resources' +redirect_to: 'https://design.gitlab.com/resources/design-resources/' --- -The content of this document was moved into the [GitLab Design System](https://design.gitlab.com/). +The content of this document was moved into the [GitLab Design System](https://design.gitlab.com/resources/design-resources/). |