kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2020-11-20 03:09:15 +00:00
parent 7a84f32e22
commit b0348fa272
58 changed files with 334 additions and 452 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
.gitlab/issue_templates/Security Release Tracking Issue.md
View File

@ -1,41 +0,0 @@
<!--
# Read me first!
Set the title to: `Security Release: 12.2.X, 12.1.X, and 12.0.X`
-->
:warning: **Only Release Managers and members of the AppSec team can edit the description of this issue**
-------
## Version issues:
12.2.X, 12.1.X, 12.0.X: {release task link}
## Issues in GitLab Security
To include your issue and merge requests in this Security Release, please mark
your security issues as related to this release tracking issue. You can do this
in the "Linked issues" section below this issue description.
:warning: If your security issues are not marked as related to this release
tracking issue, their merge requests will not be included in the security
release.
### Branches to target in GitLab Security
Your Security Implementation Issue should have `4` merge requests associated:
- [master and 3 backports](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/developer.md#backports)
- Backports should target the stable branches for the versions mentioned included in this Security Release
## Blog post
Security: {https://gitlab.com/gitlab-org/security/www-gitlab-com/merge_requests/ link}<br/>
GitLab.com: {https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/ link}
## Email notification
{https://gitlab.com/gitlab-com/marketing/general/issues/ link}
/label ~security ~"upcoming security release"
/confidential

1
.rubocop_manual_todo.yml
View File

@ -16,7 +16,6 @@ FactoryBot/InlineAssociation:
- 'spec/factories/import_export_uploads.rb'
- 'spec/factories/merge_requests.rb'
- 'spec/factories/notes.rb'
- 'spec/factories/sent_notifications.rb'
- 'spec/factories/uploads.rb'
- 'spec/factories/wiki_pages.rb'

3
app/controllers/groups/milestones_controller.rb
View File

@ -5,9 +5,6 @@ class Groups::MilestonesController < Groups::ApplicationController
before_action :milestone, only: [:edit, :show, :update, :issues, :merge_requests, :participants, :labels, :destroy]
before_action :authorize_admin_milestones!, only: [:edit, :new, :create, :update, :destroy]
before_action do
push_frontend_feature_flag(:burnup_charts, @group, default_enabled: true)
end
feature_category :issue_tracking

3
app/controllers/projects/milestones_controller.rb
View File

@ -6,9 +6,6 @@ class Projects::MilestonesController < Projects::ApplicationController
before_action :check_issuables_available!
before_action :milestone, only: [:edit, :update, :destroy, :show, :issues, :merge_requests, :participants, :labels, :promote]
before_action do
push_frontend_feature_flag(:burnup_charts, @project, default_enabled: true)
end
# Allow read any milestone
before_action :authorize_read_milestone!

9
app/finders/issuable_finder.rb
View File

@ -339,15 +339,6 @@ class IssuableFinder
cte << items
items = klass.with(cte.to_arel).from(klass.table_name)
elsif Feature.enabled?(:pg_hint_plan_for_issuables, params.project)
items = items.optimizer_hints(<<~HINTS)
BitmapScan(
issues idx_issues_on_project_id_and_created_at_and_id_and_state_id
idx_issues_on_project_id_and_due_date_and_id_and_state_id
idx_issues_on_project_id_and_updated_at_and_id_and_state_id
index_issues_on_project_id_and_iid
)
HINTS
end
items.full_search(search, matched_columns: params[:in], use_minimum_char_limit: !use_cte_for_search?)

5
changelogs/unreleased/239177_add_checksum_into_vulnerability_remediations.yml Normal file
View File

@ -0,0 +1,5 @@
---
title: Add `checksum` column into the `vulnerability_remediations` table
merge_request: 48165
author:
type: changed

8
config/feature_flags/development/burnup_charts.yml
View File

@ -1,8 +0,0 @@
---
name: burnup_charts
introduced_by_url:
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/268350
milestone: '13.6'
type: development
group: group::project management
default_enabled: true

8
config/feature_flags/development/pg_hint_plan_for_issuables.yml
View File

@ -1,8 +0,0 @@
---
name: pg_hint_plan_for_issuables
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/46289
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/273528
milestone: '13.6'
type: development
group: group::project planning
default_enabled: false

11
db/migrate/20201119164605_add_checksum_into_vulnerability_remediations.rb Normal file
View File

@ -0,0 +1,11 @@
# frozen_string_literal: true
class AddChecksumIntoVulnerabilityRemediations < ActiveRecord::Migration[6.0]
DOWNTIME = false
def change
add_column :vulnerability_remediations, :checksum, :binary, null: false, comment: 'Stores the SHA256 checksum of the attached diff file' # rubocop:disable Rails/NotNullColumn
add_index :vulnerability_remediations, :checksum, unique: true # rubocop:disable Migration/AddIndex (Table is empty)
end
end

1
db/schema_migrations/20201119164605 Normal file
View File

@ -0,0 +1 @@
5abd2cfdf96b493f8d3ecc857f850acb95e3ea30307a72c2e6f20c5feff8f5e7

5
db/structure.sql
View File

@ -17357,10 +17357,13 @@ CREATE TABLE vulnerability_remediations (
file_store smallint,
summary text NOT NULL,
file text NOT NULL,
checksum bytea NOT NULL,
CONSTRAINT check_ac0ccabff3 CHECK ((char_length(summary) <= 200)),
CONSTRAINT check_fe3325e3ba CHECK ((char_length(file) <= 255))
);
COMMENT ON COLUMN vulnerability_remediations.checksum IS 'Stores the SHA256 checksum of the attached diff file';
CREATE SEQUENCE vulnerability_remediations_id_seq
START WITH 1
INCREMENT BY 1
@ -22334,6 +22337,8 @@ CREATE UNIQUE INDEX index_vulnerability_occurrences_on_uuid ON vulnerability_occ
CREATE INDEX index_vulnerability_occurrences_on_vulnerability_id ON vulnerability_occurrences USING btree (vulnerability_id);
CREATE UNIQUE INDEX index_vulnerability_remediations_on_checksum ON vulnerability_remediations USING btree (checksum);
CREATE UNIQUE INDEX index_vulnerability_scanners_on_project_id_and_external_id ON vulnerability_scanners USING btree (project_id, external_id);
CREATE INDEX index_vulnerability_statistics_on_letter_grade ON vulnerability_statistics USING btree (letter_grade);

2
doc/architecture/blueprints/cloud_native_build_logs/index.md
View File

@ -24,7 +24,7 @@ output to a file on a disk. This is simple, but this mechanism depends on
shared local storage - the same file needs to be available on every GitLab web
node machine, because GitLab Runner might connect to a different one every time
it performs an API request. Sidekiq also needs access to the file because when
a job is complete, a trace file contents will be sent to the object store.
a job is complete, the trace file contents are sent to the object store.
## New architecture

4
doc/architecture/blueprints/cloud_native_gitlab_pages/index.md
View File

@ -72,9 +72,9 @@ of complexity, maintenance cost and enormous, negative impact on availability.
## New GitLab Pages Architecture
- GitLab Pages is going to source domains' configuration from GitLab's internal
- GitLab Pages sources domains' configuration from GitLab's internal
API, instead of reading `config.json` files from a local shared storage.
- GitLab Pages is going to serve static content from Object Storage.
- GitLab Pages serves static content from Object Storage.
```mermaid
graph TD

4
doc/architecture/blueprints/image_resizing/index.md
View File

@ -8,11 +8,11 @@ description: 'Image Resizing'
# Image resizing for avatars and content images
Currently, we are showing all uploaded images 1:1, which is of course not ideal. To improve performance greatly we will add image resizing to the backend. There are two main areas of image resizing to consider; avatars and content images. The MVC for this implementation will focus on Avatars. Avatars requests consist of approximately 70% of total image requests. There is an identified set of sizes we intend to support which makes the scope of this first MVC very narrow. Content image resizing has many more considerations for size and features. It is entirely possible that we have two separate development efforts with the same goal of increasing performance via image resizing.
Currently, we are showing all uploaded images 1:1, which is of course not ideal. To improve performance greatly, add image resizing to the backend. There are two main areas of image resizing to consider; avatars and content images. The MVC for this implementation focuses on Avatars. Avatars requests consist of approximately 70% of total image requests. There is an identified set of sizes we intend to support which makes the scope of this first MVC very narrow. Content image resizing has many more considerations for size and features. It is entirely possible that we have two separate development efforts with the same goal of increasing performance via image resizing.
## MVC Avatar Resizing
We will implement a dynamic image resizing solution. This means image should be resized and optimized on the fly so that if we define new targeted sizes later we can add them dynamically. This would mean a huge improvement in performance as some of the measurements suggest that we can save up to 95% of our current load size. Our initial investigations indicate that we have uploaded approximately 1.65 million avatars totaling approximately 80GB in size and averaging approximately 48kb each. Early measurements indicate we can reduce the most common avatar dimensions to between 1-3kb in size, netting us a greater than 90% size reduction. For the MVC we will not consider application level caching and rely purely on HTTP based caches as implemented in CDNs and browsers, but might revisit this decision later on. To easily mitigate performance issues with avatar resizing, especially in the case of self managed, an operations feature flag will be implemented to disable dynamic image resizing.
When implementing a dynamic image resizing solution, images should be resized and optimized on the fly so that if we define new targeted sizes later we can add them dynamically. This would mean a huge improvement in performance as some of the measurements suggest that we can save up to 95% of our current load size. Our initial investigations indicate that we have uploaded approximately 1.65 million avatars totaling approximately 80GB in size and averaging approximately 48kb each. Early measurements indicate we can reduce the most common avatar dimensions to between 1-3kb in size, netting us a greater than 90% size reduction. For the MVC we don't consider application level caching and rely purely on HTTP based caches as implemented in CDNs and browsers, but might revisit this decision later on. To easily mitigate performance issues with avatar resizing, especially in the case of self managed, an operations feature flag is implemented to disable dynamic image resizing.
```mermaid
sequenceDiagram

10
doc/ci/triggers/README.md
View File

@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
type: tutorial
---
# Triggering pipelines through the API
# Triggering pipelines through the API **(CORE)**
Triggers can be used to force a pipeline rerun of a specific `ref` (branch or
tag) with an API call.
@ -270,3 +270,11 @@ Old triggers, created before GitLab 9.0 are marked as legacy.
Triggers with the legacy label do not have an associated user and only have
access to the current project. They are considered deprecated and might be
removed with one of the future versions of GitLab.
## Troubleshooting
### '404 not found' when triggering a pipeline
A response of `{"message":"404 Not Found"}` when triggering a pipeline might be caused
by using a Personal Access Token instead of a trigger token. [Add a new trigger](#adding-a-new-trigger)
and use that token to authenticate when triggering a pipeline.

257
doc/ci/yaml/README.md
View File

@ -233,7 +233,7 @@ There are also two edge cases worth mentioning:
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29654) in GitLab 12.5
The top-level `workflow:` keyword determines whether or not a pipeline is created.
It accepts a single `rules:` keyword that is similar to [`rules:` defined within jobs](#rules).
It accepts a single `rules:` keyword that is similar to [`rules:` defined in jobs](#rules).
Use it to define what can trigger a new pipeline.
You can use the [`workflow:rules` templates](#workflowrules-templates) to import
@ -289,12 +289,11 @@ workflow:
```
This example prevents pipelines for schedules or `push` (branches and tags) pipelines.
The final `when: always` rule lets all other pipeline types run, **including** merge
The final `when: always` rule runs all other pipeline types, **including** merge
request pipelines.
Be careful not to have rules that match both branch pipelines
and merge request pipelines. Similar to `rules` defined in jobs, this can cause
[duplicate pipelines](#prevent-duplicate-pipelines).
If your rules match both branch pipelines and merge request pipelines,
[duplicate pipelines](#prevent-duplicate-pipelines) can occur.
#### `workflow:rules` templates
@ -306,7 +305,7 @@ for common scenarios. These templates help prevent duplicate pipelines.
The [`Branch-Pipelines` template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Workflows/Branch-Pipelines.gitlab-ci.yml)
makes your pipelines run for branches and tags.
Branch pipeline status is displayed within merge requests that use the branch
Branch pipeline status is displayed in merge requests that use the branch
as a source. However, this pipeline type does not support any features offered by
[Merge Request Pipelines](../merge_request_pipelines/), like
[Pipelines for Merge Results](../merge_request_pipelines/#pipelines-for-merged-results)
@ -339,10 +338,11 @@ include:
> - Available for Starter, Premium, and Ultimate in GitLab 10.6 and later.
> - [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/42861) to GitLab Core in 11.4.
Use the `include` keyword to include external YAML files in your CI/CD configuration. This
breaks down the CI/CD configuration into multiple files and increases readability for long configuration files.
It's also possible to have template files stored in a central repository and projects include their
configuration files. This helps avoid duplicated configuration, for example, global default variables for all projects.
Use the `include` keyword to include external YAML files in your CI/CD configuration.
You can break down one long `gitlab-ci.yml` into multiple files to increase readability,
or reduce duplication of the same configuration in multiple places.
You can also store template files in a central repository and `include` them in projects.
`include` requires the external YAML file to have the extensions `.yml` or `.yaml`,
otherwise the external file is not included.
@ -437,8 +437,7 @@ include:
```
All [nested includes](#nested-includes) are executed in the scope of the target project.
This means you can use local (relative to target project), project, remote,
or template includes.
You can use local (relative to target project), project, remote, or template includes.
##### Multiple files from a project
@ -631,8 +630,8 @@ job:
#### `before_script`
`before_script` is used to define commands that should run before each job, including
deploy jobs, but after the restoration of any [artifacts](#artifacts). This must be an array.
`before_script` is used to define an array of commands that should run before each job,
but after [artifacts](#artifacts) are restored.
Scripts specified in `before_script` are concatenated with any scripts specified
in the main [`script`](#script), and executed together in a single shell.
@ -642,25 +641,25 @@ It's possible to overwrite a globally defined `before_script` if you define it i
```yaml
default:
before_script:
- echo "Execute this in all jobs that don't already have a before_script section."
- echo "Execute this script in all jobs that don't already have a before_script section."
job1:
script:
- echo "This executes after the global before_script."
- echo "This script executes after the global before_script."
job:
before_script:
- echo "Execute this instead of the global before_script."
- echo "Execute this script instead of the global before_script."
script:
- echo "This executes after the job's `before_script`"
- echo "This script executes after the job's `before_script`"
```
You can use [YAML anchors with `before_script`](#yaml-anchors-for-scripts).
#### `after_script`
`after_script` is used to define commands that run after each job, including failed
jobs. This must be an array.
`after_script` is used to define an array of commands that run after each job,
including failed jobs.
If a job times out or is cancelled, the `after_script` commands are not executed.
Support for executing `after_script` commands for timed-out or cancelled jobs
@ -682,17 +681,17 @@ Scripts specified in `after_script` are executed in a new shell, separate from a
```yaml
default:
after_script:
- echo "Execute this in all jobs that don't already have an after_script section."
- echo "Execute this script in all jobs that don't already have an after_script section."
job1:
script:
- echo "This executes first. When it completes, the global after_script executes."
- echo "This script executes first. When it completes, the global after_script executes."
job:
script:
- echo "This executes first. When it completes, the job's `after_script` executes."
- echo "This script executes first. When it completes, the job's `after_script` executes."
after_script:
- echo "Execute this instead of the global after_script."
- echo "Execute this script instead of the global after_script."
```
You can use [YAML anchors with `after_script`](#yaml-anchors-for-scripts).
@ -848,9 +847,8 @@ If you do want to include the `rake test`, see [`before_script`](#before_script)
`.tests` in this example is a [hidden job](#hide-jobs), but it's
possible to inherit from regular jobs as well.
`extends` supports multi-level inheritance. You should avoid using more than 3 levels,
but you can use as many as eleven.
The following example has two levels of inheritance:
`extends` supports multi-level inheritance. You should avoid using more than three levels,
but you can use as many as eleven. The following example has two levels of inheritance:
```yaml
.tests:
@ -916,7 +914,7 @@ rspec:
- rake rspec
```
This results in the following `rspec` job:
The result is this `rspec` job:
```yaml
rspec:
@ -955,7 +953,7 @@ For example, if you have a local `included.yml` file:
- echo Hello!
```
Then, in `.gitlab-ci.yml` you can use it like this:
Then, in `.gitlab-ci.yml`:
```yaml
include: included.yml
@ -1041,7 +1039,7 @@ For example, using `if` clauses to strictly limit when jobs run:
```yaml
job:
script: "echo Hello, Rules!"
script: echo "Hello, Rules!"
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
when: manual
@ -1070,7 +1068,7 @@ run them in all other cases:
```yaml
job:
script: "echo Hello, Rules!"
script: echo "Hello, Rules!"
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
when: never
@ -1105,7 +1103,7 @@ For example:
```yaml
job:
script: "echo This creates double pipelines!"
script: echo "This job creates double pipelines!"
rules:
- if: '$CUSTOM_VARIABLE == "false"'
when: never
@ -1117,7 +1115,7 @@ other pipelines, including **both** push (branch) and merge request pipelines. W
this configuration, every push to an open merge request's source branch
causes duplicated pipelines.
There are multiple ways to avoid this:
There are multiple ways to avoid duplicate pipelines:
- Use [`workflow: rules`](#workflowrules) to specify which types of pipelines
can run. To eliminate duplicate pipelines, use merge request pipelines only
@ -1128,7 +1126,7 @@ There are multiple ways to avoid this:
```yaml
job:
script: "echo This does NOT create double pipelines!"
script: echo "This job does NOT create double pipelines!"
rules:
- if: '$CUSTOM_VARIABLE == "true" && $CI_PIPELINE_SOURCE == "merge_request_event"'
```
@ -1142,7 +1140,7 @@ without `workflow: rules`:
```yaml
job:
script: "echo This does NOT create double pipelines!"
script: echo "This job does NOT create double pipelines!"
rules:
- if: '$CI_PIPELINE_SOURCE == "push"'
when: never
@ -1153,7 +1151,7 @@ Do not include both push and merge request pipelines in the same job:
```yaml
job:
script: "echo This creates double pipelines!"
script: echo "This job creates double pipelines!"
rules:
- if: '$CI_PIPELINE_SOURCE == "push"'
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
@ -1165,10 +1163,10 @@ and `rules` can cause issues that are difficult to troubleshoot:
```yaml
job-with-no-rules:
script: "echo This job runs in branch pipelines."
script: echo "This job runs in branch pipelines."
job-with-rules:
script: "echo This job runs in merge request pipelines."
script: echo "This job runs in merge request pipelines."
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
```
@ -1211,7 +1209,7 @@ For example:
```yaml
job:
script: "echo Hello, Rules!"
script: echo "Hello, Rules!"
rules:
- if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/ && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
when: always
@ -1244,7 +1242,7 @@ check the value of the `$CI_PIPELINE_SOURCE` variable:
| `external` | When using CI services other than GitLab. |
| `external_pull_request_event` | When an external pull request on GitHub is created or updated. See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). |
| `merge_request_event` | For pipelines created when a merge request is created or updated. Required to enable [merge request pipelines](../merge_request_pipelines/index.md), [merged results pipelines](../merge_request_pipelines/pipelines_for_merged_results/index.md), and [merge trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md). |
| `parent_pipeline` | For pipelines triggered by a [parent/child pipeline](../parent_child_pipelines.md) with `rules`, use this in the child pipeline configuration so that it can be triggered by the parent pipeline. |
| `parent_pipeline` | For pipelines triggered by a [parent/child pipeline](../parent_child_pipelines.md) with `rules`. Use this pipeline source in the child pipeline configuration so that it can be triggered by the parent pipeline. |
| `pipeline` | For [multi-project pipelines](../multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../multi_project_pipelines.md#triggering-multi-project-pipelines-through-api), or the [`trigger`](#trigger) keyword. |
| `push` | For pipelines triggered by a `git push` event, including for branches and tags. |
| `schedule` | For [scheduled pipelines](../pipelines/schedules.md). |
@ -1256,7 +1254,7 @@ For example:
```yaml
job:
script: "echo Hello, Rules!"
script: echo "Hello, Rules!"
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule"'
when: manual
@ -1272,7 +1270,7 @@ Another example:
```yaml
job:
script: "echo Hello, Rules!"
script: echo "Hello, Rules!"
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
- if: '$CI_PIPELINE_SOURCE == "schedule"'
@ -1394,9 +1392,7 @@ Feature.disable(:ci_variable_expansion_in_rules_changes)
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24021) in GitLab 12.4.
`exists` accepts an array of paths and matches if any of these paths exist
as files in the repository.
For example:
as files in the repository:
```yaml
job:
@ -1406,10 +1402,7 @@ job:
- Dockerfile
```
You can also use glob patterns to match multiple files in any directory within
the repository.
For example:
You can also use glob patterns to match multiple files in any directory in the repository:
```yaml
job:
@ -1426,7 +1419,7 @@ checks. After the 10,000th check, rules with patterned globs always match.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30235) in GitLab 12.8.
You can use [`allow_failure: true`](#allow_failure) within `rules:` to allow a job to fail, or a manual job to
You can use [`allow_failure: true`](#allow_failure) in `rules:` to allow a job to fail, or a manual job to
wait for action, without stopping the pipeline itself. All jobs using `rules:` default to `allow_failure: false`
if `allow_failure:` is not defined.
@ -1436,7 +1429,7 @@ triggered by the particular rule.
```yaml
job:
script: "echo Hello, Rules!"
script: echo "Hello, Rules!"
rules:
- if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
when: manual
@ -1465,7 +1458,7 @@ docker build:
- Dockerfile
- docker/scripts/*
when: manual
# - when: never would be redundant here, this is implied any time rules are listed.
# - "when: never" would be redundant here. It is implied any time rules are listed.
```
Keywords such as `branches` or `refs` that are available for
@ -1792,8 +1785,8 @@ refs only:
CAUTION: **Caution:**
In pipelines with [sources other than the three above](../variables/predefined_variables.md)
`changes` can't determine if a given file is new or old and always returns `true`.
This includes pipelines triggered by pushing new tags. Configuring jobs to use `only: changes`
with other `only: refs` keywords is possible, but not recommended.
You can configure jobs to use `only: changes` with other `only: refs` keywords. However,
those jobs ignore the changes and always run.
A basic example of using `only: changes`:
@ -1823,7 +1816,7 @@ If you use `only:changes` with [only allow merge requests to be merged if the pi
you should [also use `only:merge_requests`](#using-onlychanges-with-pipelines-for-merge-requests). Otherwise it may not work as expected.
You can also use glob patterns to match multiple files in either the root directory
of the repository, or in _any_ directory within the repository. However, they must be wrapped
of the repository, or in _any_ directory in the repository. However, they must be wrapped
in double quotes or GitLab can't parse them. For example:
```yaml
@ -1862,10 +1855,9 @@ With [pipelines for merge requests](../merge_request_pipelines/index.md),
it's possible to define a job to be created based on files modified
in a merge request.
To deduce the correct base SHA of the source branch, we recommend combining
this keyword with `only: [merge_requests]`. This way, file differences are correctly
calculated from any further commits, thus all changes in the merge requests are properly
tested in pipelines.
Use this keyword with `only: [merge_requests]` so GitLab can find the correct base
SHA of the source branch. File differences are correctly calculated from any further
commits, and all changes in the merge requests are properly tested in pipelines.
For example:
@ -1933,8 +1925,8 @@ runs.
Use the `needs:` keyword to execute jobs out-of-order. Relationships between jobs
that use `needs` can be visualized as a [directed acyclic graph](../directed_acyclic_graph/index.md).
This lets you run some jobs without waiting for other ones, disregarding stage ordering
so you can have multiple stages running concurrently.
You can ignore stage ordering and run some jobs without waiting for others to complete.
Jobs in multiple stages can run concurrently.
Let's consider the following example:
@ -2002,7 +1994,7 @@ This example creates four paths of execution:
##### Changing the `needs:` job limit **(CORE ONLY)**
The maximum number of jobs that can be defined within `needs:` defaults to 50.
The maximum number of jobs that can be defined in `needs:` defaults to 50.
A GitLab administrator with [access to the GitLab Rails console](../../administration/feature_flags.md)
can choose a custom limit. For example, to set the limit to 100:
@ -2211,16 +2203,13 @@ failure.
`when` can be set to one of the following values:
1. `on_success` - execute job only when all jobs from prior stages
succeed (or are considered succeeding because they have `allow_failure: true`).
This is the default.
1. `on_failure` - execute job only when at least one job from prior stages
fails.
1. `always` - execute job regardless of the status of jobs from prior stages.
1. `manual` - execute job manually. Read about
[manual jobs](#whenmanual) below.
1. `delayed` - execute job after a certain period (added in GitLab 11.14).
Read about [delayed jobs](#whendelayed) below.
1. `on_success` (default) - Execute job only when all jobs in earlier stages succeed,
or are considered successful because they have `allow_failure: true`.
1. `on_failure` - Execute job only when at least one job in an earlier stage fails.
1. `always` - Execute job regardless of the status of jobs in earlier stages.
1. `manual` - Execute job [manually](#whenmanual).
1. `delayed` - [Delay the execution of a job](#whendelayed) for a specified duration.
Added in GitLab 11.14.
1. `never`:
- With [`rules`](#rules), don't execute job.
- With [`workflow:rules`](#workflowrules), don't run pipeline.
@ -2318,7 +2307,7 @@ the users associated with a protected environment to trigger manual jobs, which
- More precisely limit who can deploy to an environment.
- Block a pipeline until an approved user "approves" it.
To do this, you must:
To protect a manual job:
1. Add an `environment` to the job. For example:
@ -2341,10 +2330,10 @@ To do this, you must:
this list can trigger this manual job, as well as GitLab administrators
who are always able to use protected environments.
Additionally, if you define a manual job as blocking by adding `allow_failure: false`,
the pipeline's next stages don't run until the manual job is triggered. You can use this
to define a list of users allowed to "approve" later pipeline
stages by triggering the blocking manual job.
You can use protected environments with blocking manual jobs to have a list of users
allowed to approve later pipeline stages. Add `allow_failure: false` to the protected
manual job and the pipeline's next stages only run after the manual job is triggered
by authorized users.
#### `when:delayed`
@ -2363,7 +2352,7 @@ provided. `start_in` key must be less than or equal to one week. Examples of val
- `1 week`
When there is a delayed job in a stage, the pipeline doesn't progress until the delayed job has finished.
This means this keyword can also be used for inserting delays between different stages.
This keyword can also be used for inserting delays between different stages.
The timer of a delayed job starts immediately after the previous stage has completed.
Similar to other types of jobs, a delayed job's timer doesn't start unless the previous stage passed.
@ -2517,8 +2506,8 @@ Also in the example, `GIT_STRATEGY` is set to `none`. If the
the runner won’t try to check out the code after the branch is deleted.
The example also overwrites global variables. If your `stop` `environment` job depends
on global variables, you can use [anchor variables](#yaml-anchors-for-variables) when you set the `GIT_STRATEGY`.
This changes the job without overriding the global variables.
on global variables, use [anchor variables](#yaml-anchors-for-variables) when you set the `GIT_STRATEGY`
to change the job without overriding the global variables.
The `stop_review_app` job is **required** to have the following keywords defined:
@ -2607,16 +2596,12 @@ deploy as review app:
url: https://$CI_ENVIRONMENT_SLUG.example.com/
```
The `deploy as review app` job is marked as deployment to dynamically
create the `review/$CI_COMMIT_REF_NAME` environment, where `$CI_COMMIT_REF_NAME`
The `deploy as review app` job is marked as a deployment to dynamically
create the `review/$CI_COMMIT_REF_NAME` environment. `$CI_COMMIT_REF_NAME`
is an [environment variable](../variables/README.md) set by the runner. The
`$CI_ENVIRONMENT_SLUG` variable is based on the environment name, but suitable
for inclusion in URLs. In this case, if the `deploy as review app` job is run
in a branch named `pow`, this environment would be accessible with an URL like
`https://review-pow.example.com/`.
This implies that the underlying server that hosts the application
is properly configured.
for inclusion in URLs. If the `deploy as review app` job runs in a branch named
`pow`, this environment would be accessible with a URL like `https://review-pow.example.com/`.
The common use case is to create dynamic environments for branches and use them
as Review Apps. You can see an example that uses Review Apps at
@ -2625,8 +2610,7 @@ as Review Apps. You can see an example that uses Review Apps at
### `cache`
`cache` is used to specify a list of files and directories that should be
cached between jobs. You can only use paths that are within the local working
copy.
cached between jobs. You can only use paths that are in the local working copy.
If `cache` is defined outside the scope of jobs, it means it's set
globally and all jobs use that definition.
@ -2681,11 +2665,9 @@ Otherwise cache content can be overwritten.
#### `cache:key`
> Introduced in GitLab Runner v1.0.0.
The `key` keyword defines the affinity of caching between jobs.
You can have a single cache for all jobs, cache per-job, cache per-branch,
or any other way that fits your workflow. This way, you can fine tune caching,
or any other way that fits your workflow. You can fine tune caching,
including caching data between different jobs or even different branches.
The `cache:key` variable can use any of the
@ -2841,9 +2823,9 @@ rspec:
`cache:when` defines when to save the cache, based on the status of the job. You can
set `cache:when` to:
- `on_success` - save the cache only when the job succeeds. This is the default.
- `on_failure` - save the cache only when the job fails.
- `always` - save the cache regardless of the job status.
- `on_success` (default): Save the cache only when the job succeeds.
- `on_failure`: Save the cache only when the job fails.
- `always`: Always save the cache.
For example, to store a cache whether or not the job fails or succeeds:
@ -2864,9 +2846,8 @@ job are persisted for future runs. This behavior is known as the `pull-push` cac
policy.
If you know the job does not alter the cached files, you can skip the upload step
by setting `policy: pull` in the job specification. Typically, this would be
twinned with an ordinary cache job at an earlier stage to ensure the cache
is updated from time to time:
by setting `policy: pull` in the job specification. You can add an ordinary cache
job at an earlier stage to ensure the cache is updated from time to time:
```yaml
stages:
@ -2893,9 +2874,8 @@ rspec:
- bundle exec rspec ...
```
This helps to speed up job execution and reduce load on the cache server.
It is especially helpful when you have a large number of cache-using jobs executing in
parallel.
The `pull` policy speeds up job execution and reduces load on the cache server. It
can be used when you have many jobs that use caches executing in parallel.
If you have a job that unconditionally recreates the cache without
referring to its previous contents, you can skip the download step.
@ -3163,9 +3143,9 @@ failure.
`artifacts:when` can be set to one of the following values:
1. `on_success` - upload artifacts only when the job succeeds. This is the default.
1. `on_failure` - upload artifacts only when the job fails.
1. `always` - upload artifacts regardless of the job status.
1. `on_success` (default): Upload artifacts only when the job succeeds.
1. `on_failure`: Upload artifacts only when the job fails.
1. `always`: Always upload artifacts.
For example, to upload artifacts only when a job fails:
@ -3397,7 +3377,7 @@ Possible values for `when` are:
The test there makes sure that all documented
values are valid as a configuration option and therefore should always
stay in sync with this documentation.
-->
-->
- `always`: Retry on any failure (default).
- `unknown_failure`: Retry when the failure reason is unknown.
@ -3440,16 +3420,11 @@ exceed the runner-specific timeout.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/21480) in GitLab 11.5.
Use `parallel` to configure how many instances of a job to run in
parallel. This value can be from 2 to 50.
Use `parallel` to configure how many instances of a job to run in parallel.
The value can be from 2 to 50.
This creates N instances of the same job that run in parallel. They are named
sequentially from `job_name 1/N` to `job_name N/N`.
For every job, `CI_NODE_INDEX` and `CI_NODE_TOTAL` [environment variables](../variables/README.md#predefined-environment-variables) are set.
Marking a job to be run in parallel requires adding `parallel` to your configuration
file. For example:
The `parallel` keyword creates N instances of the same job that run in parallel.
They are named sequentially from `job_name 1/N` to `job_name N/N`:
```yaml
test:
@ -3457,10 +3432,12 @@ test:
parallel: 5
```
Parallelize tests suites across parallel jobs.
Different languages have different tools to facilitate this.
Every parallel job has a `CI_NODE_INDEX` and `CI_NODE_TOTAL`
[environment variable](../variables/README.md#predefined-environment-variables) set.
For example, using [Semaphore Test Boosters](https://github.com/renderedtext/test-boosters) and RSpec to run some Ruby tests:
Different languages and test suites have different methods to enable parallelization.
For example, use [Semaphore Test Boosters](https://github.com/renderedtext/test-boosters)
and RSpec to run Ruby tests in parallel:
```ruby
# Gemfile
@ -3479,7 +3456,7 @@ test:
```
CAUTION: **Caution:**
Test Boosters reports usages statistics to the author.
Test Boosters reports usage statistics to the author.
You can then navigate to the **Jobs** tab of a new pipeline build and see your RSpec
job split into three separate jobs.
@ -3514,7 +3491,8 @@ deploystacks:
STACK: [data, processing]
```
This generates 10 parallel `deploystacks` jobs, each with different values for `PROVIDER` and `STACK`:
This example generates 10 parallel `deploystacks` jobs, each with different values
for `PROVIDER` and `STACK`:
```plaintext
deploystacks: [aws, monitoring]
@ -3529,7 +3507,7 @@ deploystacks: [vultr, data]
deploystacks: [vultr, processing]
```
Job naming style [was improved](https://gitlab.com/gitlab-org/gitlab/-/issues/230452) in GitLab 13.4.
The job naming style was [improved in GitLab 13.4](https://gitlab.com/gitlab-org/gitlab/-/issues/230452).
### `trigger`
@ -3782,8 +3760,8 @@ deploy-to-production:
In this case, two `deploy-to-production` jobs in two separate pipelines can never run at the same time. As a result,
you can ensure that concurrent deployments never happen to the production environment.
There can be multiple `resource_group`s defined per environment. A good use case for this
is when deploying to physical devices. You may have multiple physical devices that
You can define multiple resource groups per environment. For example,
when deploying to physical devices, you may have multiple physical devices. Each device
can be deployed to, but there can be only one deployment per device at any given time.
The `resource_group` value can only contain letters, digits, `-`, `_`, `/`, `$`, `{`, `}`, `.`, and spaces.
@ -3819,8 +3797,9 @@ image: registry.gitlab.com/gitlab-org/release-cli:latest
#### Script
All jobs require a `script` tag at a minimum. A `:release` job can use the output of a
`:script` tag, but if this is not necessary, a placeholder script can be used, for example:
All jobs except [trigger](#trigger) jobs must have the `script` keyword. A `release`
job can use the output from script commands, but a placeholder script can be used if
the script is not needed:
```yaml
script:
@ -3980,15 +3959,16 @@ tags. These options cannot be used together, so choose one:
#### Release assets as Generic packages
You can use [Generic packages](../../user/packages/generic_packages/) to host your release assets.
For a complete example of how to do this, see the [example in the repository](https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs/examples/release-assets-as-generic-package/).
For a complete example, see the [Release assets as Generic packages](https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs/examples/release-assets-as-generic-package/)
project.
#### `releaser-cli` command line
The entries under the `:release` node are transformed into a `bash` command line and sent
The entries under the `release` node are transformed into a `bash` command line and sent
to the Docker container, which contains the [release-cli](https://gitlab.com/gitlab-org/release-cli).
You can also call the `release-cli` directly from a `script` entry.
The YAML described above would be translated into a CLI command like this:
For example, using the YAML described above:
```shell
release-cli create --name "Release $CI_COMMIT_SHA" --description "Created using the release-cli $EXTRA_DESCRIPTION" --tag-name "v${MAJOR}.${MINOR}.${REVISION}" --ref "$CI_COMMIT_SHA" --released-at "2020-07-15T08:00:00Z" --milestone "m1" --milestone "m2" --milestone "m3"
@ -4112,7 +4092,7 @@ deploy_review_job:
You can use only integers and strings for the variable's name and value.
If you define a variable at the top level of the `gitlab-ci.yml` file, it is global,
meaning it applies to all jobs. If you define a variable within a job, it's available
meaning it applies to all jobs. If you define a variable in a job, it's available
to that job only.
If a variable of the same name is defined globally and for a specific job, the
@ -4160,7 +4140,7 @@ to provide templates for your jobs. When there are duplicate keys, GitLab
performs a reverse deep merge based on the keys.
You can't use YAML anchors across multiple files when leveraging the [`include`](#include)
feature. Anchors are only valid within the file they were defined in. Instead
feature. Anchors are only valid in the file they were defined in. Instead
of using YAML anchors, you can use the [`extends` keyword](#extends).
The following example uses anchors and map merging. It creates two jobs,
@ -4187,7 +4167,7 @@ test2:
`&` sets up the name of the anchor (`job_definition`), `<<` means "merge the
given hash into the current one", and `*` includes the named anchor
(`job_definition` again). The expanded version looks like this:
(`job_definition` again). The expanded version of the example above is:
```yaml
.job_template:
@ -4213,10 +4193,9 @@ test2:
- test2 project
```
Let's see another example. This time we use anchors to define two sets
of services. This configuration creates two jobs, `test:postgres` and `test:mysql`, that
share the `script` directive defined in `.job_template`, and the `services`
directive defined in `.postgres_services` and `.mysql_services` respectively:
You can use anchors to define two sets of services. For example, `test:postgres`
and `test:mysql` share the `script` defined in `.job_template`, but use different
`services`, defined in `.postgres_services` and `.mysql_services`:
```yaml
.job_template: &job_definition
@ -4246,7 +4225,7 @@ test:mysql:
services: *mysql_definition
```
The expanded version looks like this:
The expanded version is:
```yaml
.job_template:
@ -4296,13 +4275,13 @@ and [`after_script`](#after_script) to use predefined commands in multiple jobs:
```yaml
.some-script: &some-script
- echo "Execute this in `before_script` sections"
- echo "Execute this script in `before_script` sections"
.some-script-before: &some-script-before
- echo "Execute this in `script` sections"
- echo "Execute this script in `script` sections"
.some-script-after: &some-script-after
- echo "Execute this in `after_script` sections"
- echo "Execute this script in `after_script` sections"
job_name:
before_script:

2
doc/development/new_fe_guide/development/performance.md
View File

@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
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/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`.
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 are pushed 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:

2
doc/integration/cas.md
View File

@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# CAS OmniAuth Provider
To enable the CAS OmniAuth provider you must register your application with your CAS instance. This requires the service URL GitLab will supply to CAS. It should be something like: `https://gitlab.example.com:443/users/auth/cas3/callback?url`. By default handling for SLO is enabled, you only need to configure CAS for backchannel logout.
To enable the CAS OmniAuth provider you must register your application with your CAS instance. This requires the service URL GitLab supplies to CAS. It should be something like: `https://gitlab.example.com:443/users/auth/cas3/callback?url`. By default handling for SLO is enabled, you only need to configure CAS for backchannel logout.
1. On your GitLab server, open the configuration file.

10
doc/integration/jenkins.md
View File

@ -54,9 +54,9 @@ Grant a GitLab user access to the select GitLab projects.
1. Create a new GitLab user, or choose an existing GitLab user.
This account will be used by Jenkins to access the GitLab projects. We recommend creating a GitLab
This account is used by Jenkins to access the GitLab projects. We recommend creating a GitLab
user for only this purpose. If you use a person's account, and their account is deactivated or
deleted, the GitLab-Jenkins integration will stop working.
deleted, the GitLab-Jenkins integration stops working.
1. Grant the user permission to the GitLab projects.
@ -96,12 +96,12 @@ For more information, see GitLab Plugin documentation about
## Configure the Jenkins project
Set up the Jenkins project you’re going to run your build on.
Set up the Jenkins project you intend to run your build on.
1. On your Jenkins instance, go to **New Item**.
1. Enter the project's name.
1. Choose between **Freestyle** or **Pipeline** and click **OK**.
We recommend a Freestyle project, because the Jenkins plugin will update the build status on
We recommend a Freestyle project, because the Jenkins plugin updates the build status on
GitLab. In a Pipeline project, you must configure a script to update the status on GitLab.
1. Choose your GitLab connection from the dropdown.
1. Check the **Build when a change is pushed to GitLab** checkbox.
@ -186,7 +186,7 @@ If those are present, the request is exceeding the
[webhook timeout](../user/project/integrations/webhooks.md#receiving-duplicate-or-multiple-webhook-requests-triggered-by-one-event),
which is set to 10 seconds by default.
To fix this the `gitlab_rails['webhook_timeout']` value will need to be increased
To fix this the `gitlab_rails['webhook_timeout']` value must be increased
in the `gitlab.rb` config file, followed by the [`gitlab-ctl reconfigure` command](../administration/restart_gitlab.md).
If you don't find the errors above, but do find *duplicate* entries like below (in `/var/log/gitlab/gitlab-rail`), this

54
doc/raketasks/backup_restore.md
View File

@ -16,7 +16,7 @@ of GitLab on which it was created. The best way to migrate your repositories
from one server to another is through backup restore.
CAUTION: **Warning:**
GitLab won't back up items that aren't stored in the filesystem. If you're
GitLab doesn't back up items that aren't stored in the filesystem. If you're
using [object storage](../administration/object_storage.md), be sure to enable
backups with your object storage provider, if desired.
@ -38,8 +38,8 @@ system. If you installed GitLab:
## Backup timestamp
The backup archive will be saved in `backup_path`, which is specified in the
`config/gitlab.yml` file. The filename will be `[TIMESTAMP]_gitlab_backup.tar`,
The backup archive is saved in `backup_path`, which is specified in the
`config/gitlab.yml` file. The filename is `[TIMESTAMP]_gitlab_backup.tar`,
where `TIMESTAMP` identifies the time at which each backup was created, plus
the GitLab version. The timestamp is needed if you need to restore GitLab and
multiple backups are available.
@ -112,8 +112,8 @@ kubectl exec -it <gitlab task-runner pod> backup-utility
```
Similar to the Kubernetes case, if you have scaled out your GitLab cluster to
use multiple application servers, you should pick a designated node (that won't
be auto-scaled away) for running the backup Rake task. Because the backup Rake
use multiple application servers, you should pick a designated node (that isn't
auto-scaled away) for running the backup Rake task. Because the backup Rake
task is tightly coupled to the main Rails application, this is typically a node
on which you're also running Unicorn/Puma or Sidekiq.
@ -200,11 +200,11 @@ data locations to the backup using the Linux command `tar` and `gzip`. This work
fine in most cases, but can cause problems when data is rapidly changing.
When data changes while `tar` is reading it, the error `file changed as we read
it` may occur, and will cause the backup process to fail. To combat this, 8.17
it` may occur, and causes the backup process to fail. To combat this, 8.17
introduces a new backup strategy called `copy`. The strategy copies data files
to a temporary location before calling `tar` and `gzip`, avoiding the error.
A side-effect is that the backup process will take up to an additional 1X disk
A side-effect is that the backup process takes up to an additional 1X disk
space. The process does its best to clean up the temporary files at each stage
so the problem doesn't compound, but it could be a considerable change for large
installations. This is why the `copy` strategy is not the default in 8.17.
@ -221,7 +221,7 @@ Users of GitLab 12.1 and earlier should use the command `gitlab-rake gitlab:back
#### Backup filename
CAUTION: **Warning:**
If you use a custom backup filename, you will not be able to
If you use a custom backup filename, you can't
[limit the lifetime of the backups](#limit-backup-lifetime-for-local-files-prune-old-backups).
By default, a backup file is created according to the specification in the
@ -235,8 +235,8 @@ sudo gitlab-backup create BACKUP=dump
Users of GitLab 12.1 and earlier should use the command `gitlab-rake gitlab:backup:create` instead.
The resulting file will then be `dump_gitlab_backup.tar`. This is useful for
systems that make use of rsync and incremental backups, and will result in
The resulting file is named `dump_gitlab_backup.tar`. This is useful for
systems that make use of rsync and incremental backups, and results in
considerably faster transfer speeds.
#### Rsyncable
@ -271,8 +271,8 @@ variable `SKIP`. The available options are:
Use a comma to specify several options at the same time:
All wikis will be backed up as part of the `repositories` group. Non-existent
wikis will be skipped during a backup.
All wikis are backed up as part of the `repositories` group. Non-existent
wikis are skipped during a backup.
For Omnibus GitLab packages:
@ -297,7 +297,7 @@ harmful, so you can skip this step by adding `tar` to the `SKIP` environment
variable.
Adding `tar` to the `SKIP` variable leaves the files and directories containing the
backup in the directory used for the intermediate files. These files will be
backup in the directory used for the intermediate files. These files are
overwritten when a new backup is created, so you should make sure they are copied
elsewhere, because you can only have one backup on the system.
@ -454,7 +454,7 @@ For installations from source:
1. [Restart GitLab](../administration/restart_gitlab.md#installations-from-source)
for the changes to take effect
If you're uploading your backups to S3, you'll probably want to create a new
If you're uploading your backups to S3, you should create a new
IAM user with restricted access rights. To give the upload user access only for
uploading backups create the following IAM profile, replacing `my.s3.bucket`
with the name of your bucket:
@ -620,7 +620,7 @@ as (for Omnibus packages, this is the `git` user).
The `backup_upload_remote_directory` _must_ be set in addition to the
`local_root` key. This is the sub directory inside the mounted directory that
backups will be copied to, and will be created if it does not exist. If the
backups are copied to, and is created if it does not exist. If the
directory that you want to copy the tarballs to is the root of your mounted
directory, use `.` instead.
@ -667,7 +667,7 @@ For installations from source:
#### Backup archive permissions
The backup archives created by GitLab (`1393513186_2014_02_27_gitlab_backup.tar`)
will have owner/group `git`/`git` and 0600 permissions by default. This is
have the owner/group `git`/`git` and 0600 permissions by default. This is
meant to avoid other system users reading GitLab's data. If you need the backup
archives to have different permissions, you can use the `archive_permissions`
setting.
@ -741,7 +741,7 @@ output if there aren't any errors. This is recommended to reduce cron spam.
### Limit backup lifetime for local files (prune old backups)
CAUTION: **Warning:**
The process described in this section will not work if you used a [custom filename](#backup-filename)
The process described in this section don't work if you used a [custom filename](#backup-filename)
for your backups.
To prevent regular backups from using all your disk space, you may want to set a limited lifetime
@ -791,8 +791,8 @@ once before attempting to perform it in a production environment.
You can restore a backup only to _the exact same version and type (CE/EE)_ of
GitLab that you created it on (for example CE 9.1.0).
If your backup is a different version than the current installation, you'll
need to [downgrade your GitLab installation](https://docs.gitlab.com/omnibus/update/README.html#downgrade)
If your backup is a different version than the current installation, you must
[downgrade your GitLab installation](https://docs.gitlab.com/omnibus/update/README.html#downgrade)
before restoring the backup.
### Restore prerequisites
@ -800,17 +800,17 @@ before restoring the backup.
You need to have a working GitLab installation before you can perform a
restore. This is because the system user performing the restore actions (`git`)
is usually not allowed to create or delete the SQL database needed to import
data into (`gitlabhq_production`). All existing data will be either erased
data into (`gitlabhq_production`). All existing data is either erased
(SQL) or moved to a separate directory (such as repositories and uploads).
To restore a backup, you'll also need to restore `/etc/gitlab/gitlab-secrets.json`
To restore a backup, you must restore `/etc/gitlab/gitlab-secrets.json`
(for Omnibus packages) or `/home/git/gitlab/.secret` (for installations from
source). This file contains the database encryption key,
[CI/CD variables](../ci/variables/README.md#gitlab-cicd-environment-variables), and
variables used for [two-factor authentication](../user/profile/account/two_factor_authentication.md).
If you fail to restore this encryption key file along with the application data
backup, users with two-factor authentication enabled and GitLab Runner will
lose access to your GitLab server.
backup, users with two-factor authentication enabled and GitLab Runner
loses access to your GitLab server.
You may also want to restore any TLS keys, certificates, or
[SSH host keys](https://superuser.com/questions/532040/copy-ssh-keys-from-one-server-to-another-server/532079#532079).
@ -825,7 +825,7 @@ more of the following options:
- `BACKUP=timestamp_of_backup`: Required if more than one backup exists.
Read what the [backup timestamp is about](#backup-timestamp).
- `force=yes`: Doesn't ask if the authorized_keys file should get regenerated,
and assumes 'yes' for warning that database tables will be removed,
and assumes 'yes' for warning about database tables being removed,
enabling the "Write to authorized_keys file" setting, and updating LDAP
providers.
@ -1033,7 +1033,7 @@ Example: LVM snapshots + rsync
> A GitLab server using Omnibus GitLab, with an LVM logical volume mounted at `/var/opt/gitlab`.
> Replicating the `/var/opt/gitlab` directory using rsync would not be reliable because too many files would change while rsync is running.
> Instead of rsync-ing `/var/opt/gitlab`, we create a temporary LVM snapshot, which we mount as a read-only filesystem at `/mnt/gitlab_backup`.
> Now we can have a longer running rsync job which will create a consistent replica on the remote server.
> Now we can have a longer running rsync job which creates a consistent replica on the remote server.
> The replica includes all repositories, uploads and PostgreSQL data.
If you're running GitLab on a virtualized server, you can possibly also create
@ -1045,7 +1045,7 @@ practical use.
Do NOT backup or restore GitLab through a PgBouncer connection. These
tasks must [bypass PgBouncer and connect directly to the PostgreSQL primary database node](#bypassing-pgbouncer),
or they will cause a GitLab outage.
or they cause a GitLab outage.
When the GitLab backup or restore task is used with PgBouncer, the
following error message is shown:
@ -1170,7 +1170,7 @@ unexpected behaviors, such as:
In this case, you must reset all the tokens for CI/CD variables and
runner authentication, which is described in more detail in the following
sections. After resetting the tokens, you should be able to visit your project
and the jobs will have started running again.
and the jobs begin running again.
Use the information in the following sections at your own risk.

14
doc/raketasks/import.md
View File

@ -13,13 +13,13 @@ please use [our project-based import/export](../user/project/settings/import_exp
Note that:
- The owner of the project will be the first administrator.
- The groups will be created as needed, including subgroups.
- The owner of the group will be the first administrator.
- Existing projects will be skipped.
- The owner of the project is the first administrator.
- The groups are created as needed, including subgroups.
- The owner of the group is the first administrator.
- Existing projects are skipped.
- Projects in hashed storage may be skipped. For more information, see
[Importing bare repositories from hashed storage](#importing-bare-repositories-from-hashed-storage).
- The existing Git repositories will be moved from disk (removed from the original path).
- The existing Git repositories ware moved from disk (removed from the original path).
To import bare repositories into a GitLab instance:
@ -35,8 +35,8 @@ To import bare repositories into a GitLab instance:
1. Copy your bare repositories inside this newly created folder. Note:
- Any `.git` repositories found on any of the subfolders will be imported as projects.
- Groups will be created as needed, these could be nested folders.
- Any `.git` repositories found on any of the subfolders are imported as projects.
- Groups are created as needed, these could be nested folders.
For example, if we copy the repositories to `/var/opt/gitlab/git-data/repository-import-2020-08-22`,
and repository `A` needs to be under the groups `G1` and `G2`, it must be created under those folders:

6
doc/raketasks/user_management.md
View File

@ -98,11 +98,11 @@ the leaked key without forcing all users to change their 2FA details.
To rotate the two-factor authentication encryption key:
1. Look up the old key. This is in the `config/secrets.yml` file, but **make sure you're working
with the production section**. The line you're interested in will look like this:
with the production section**. The line you're interested in looks like this:
```yaml
production:
otp_key_base: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
otp_key_base: fffffffffffffffffffffffffffffffffffffffffffffff
```
1. Generate a new secret:
@ -130,7 +130,7 @@ To rotate the two-factor authentication encryption key:
```
The `<old key>` value can be read from `config/secrets.yml` (`<new key>` was
generated earlier). The **encrypted** values for the user 2FA secrets will be
generated earlier). The **encrypted** values for the user 2FA secrets are
written to the specified `filename`. You can use this to rollback in case of
error.

46
doc/subscriptions/gitlab_com/index.md
View File

@ -1,6 +1,6 @@
---
stage: none
group: unassigned
stage: fulfillment
group: fulfillment
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
type: index, reference
---
@ -11,7 +11,7 @@ GitLab.com is GitLab Inc.'s software-as-a-service offering. You don't need to
install anything to use GitLab.com, you only need to
[sign up](https://gitlab.com/users/sign_up) and start using GitLab straight away.
In this page we'll go through the details of your GitLab.com subscription.
This page reviews the details of your GitLab.com subscription.
## Choose a GitLab.com group or personal subscription
@ -20,10 +20,10 @@ On GitLab.com you can apply a subscription to either a group or a personal names
When applied to:
- A **group**, the group, all subgroups, and all projects under the selected
group on GitLab.com will have the features of the associated tier. GitLab recommends
group on GitLab.com contains the features of the associated tier. GitLab recommends
choosing a group plan when managing an organization's projects and users.
- A **personal userspace**, all projects will have features with the
subscription applied, but as it's not a group, group features won't be available.
- A **personal userspace**, all projects contain features with the
subscription applied, but as it's not a group, group features aren't available.
## Choose a GitLab.com tier
@ -64,7 +64,7 @@ To subscribe to GitLab.com:
[Customers Portal](https://customers.gitlab.com/).
1. Link your GitLab.com account with your Customers Portal account.
Once a plan has been selected, if your account is not
already linked, you will be prompted to link your account with a
already linked, GitLab prompts you to link your account with a
**Sign in to GitLab.com** button.
1. Select the namespace from the drop-down list to associate the subscription.
1. Proceed to checkout.
@ -81,7 +81,7 @@ To subscribe to GitLab.com:
[Customers Portal](https://customers.gitlab.com/).
1. Link your GitLab.com account with your Customers Portal account.
Once a plan has been selected, if your account is not
already linked, you will be prompted to link your account with a
already linked, GitLab prompts you to link your account with a
**Sign in to GitLab.com** button.
1. Select the namespace from the drop-down list to associate the subscription.
1. Proceed to checkout.
@ -109,9 +109,9 @@ to the **Billing** section of the relevant namespace:
| **Seats in subscription** | If this is a paid plan, represents the number of seats you've paid to support in your group. |
| **Seats currently in use** | Number of active seats currently in use. |
| **Max seats used** | Highest number of seats you've used. If this exceeds the seats in subscription, you may owe an additional fee for the additional users. |
| **Seats owed** | If your maximum seats used exceeds the seats in your subscription, you'll owe an additional fee for the users you've added. |
| **Seats owed** | If your maximum seats used exceeds the seats in your subscription, you owe an additional fee for the users you've added. |
| **Subscription start date** | Date your subscription started. If this is for a Free plan, is the date you transitioned off your group's paid plan. |
| **Subscription end date** | Date your current subscription will end. Does not apply to Free plans. |
| **Subscription end date** | Date your current subscription ends. Does not apply to Free plans. |
## Renew your GitLab.com subscription
@ -136,8 +136,8 @@ the contact person who manages your subscription.
It's important to regularly review your user accounts, because:
- A GitLab subscription is based on the number of users. You will pay more than
you should if you renew for too many users, while the renewal will fail if you
- A GitLab subscription is based on the number of users. You could pay more than
you should if you renew for too many users, while the renewal fails if you
attempt to renew a subscription for too few users.
- Stale user accounts can be a security risk. A regular review helps reduce this risk.
@ -172,8 +172,8 @@ previous period), log in to the [Customers Portal](https://customers.gitlab.com/
- If you see **Cancel subscription**, your subscription is set to automatically
renew at the end of the subscription period. Click it to cancel automatic renewal.
With automatic renewal enabled, the subscription will automatically renew on the
expiration date and there will be no gap in available service. An invoice will be
With automatic renewal enabled, the subscription automatically renews on the
expiration date without a gap in available service. An invoice is
generated for the renewal and available for viewing or download in the
[View invoices](https://customers.gitlab.com/receipts) page. If you have difficulty
during the renewal process, contact our
@ -193,10 +193,10 @@ To add users to a subscription:
1. Enter the number of additional users.
1. Select **Proceed to checkout**.
1. Review the **Subscription Upgrade Detail**. The system lists the total price for all users on the
system and a credit for what you've already paid. You will only be charged for the net change.
system and a credit for what you've already paid. You are only be charged for the net change.
1. Select **Confirm Upgrade**.
The following will be emailed to you:
The following is emailed to you:
- A payment receipt. You can also access this information in the Customers Portal under
[**View invoices**](https://customers.gitlab.com/receipts).
@ -222,7 +222,7 @@ it may become inaccessible, depending on the tier at expiry. Some features may n
behave as expected if you're not prepared for the expiry. For example,
[environment specific variables not being passed](https://gitlab.com/gitlab-org/gitlab/-/issues/24759).
If you renew or upgrade, your data will again be accessible.
If you renew or upgrade, your data is accessible again.
## CI pipeline minutes
@ -258,7 +258,7 @@ Your own runners can still be used even if you reach your limits.
### Purchase additional CI minutes
If you're using GitLab.com, you can purchase additional CI minutes so your
pipelines won't be blocked after you have used all your CI minutes from your
pipelines aren't blocked after you have used all your CI minutes from your
main quota. You can find pricing for additional CI/CD minutes in the
[GitLab Customers Portal](https://customers.gitlab.com/plans). Additional minutes:
@ -268,9 +268,9 @@ main quota. You can find pricing for additional CI/CD minutes in the
To purchase additional minutes for your group on GitLab.com:
1. From your group, go to **Settings > Usage Quotas**.
1. Select **Buy additional minutes** and you will be directed to the Customers Portal.
1. Select **Buy additional minutes** and GitLab directs you to the Customers Portal.
1. Locate the subscription card that's linked to your group on GitLab.com, click **Buy more CI minutes**, and complete the details about the transaction.
1. Once we have processed your payment, the extra CI minutes will be synced to your group namespace.
1. Once we have processed your payment, the extra CI minutes are synced to your group namespace.
1. To confirm the available CI minutes, go to your group, then **Settings > Usage Quotas**.
The **Additional minutes** displayed now includes the purchased additional CI minutes, plus any minutes rolled over from last month.
@ -278,8 +278,8 @@ To purchase additional minutes for your group on GitLab.com:
To purchase additional minutes for your personal namespace:
1. Click your avatar, then go to **Settings > Usage Quotas**.
1. Select **Buy additional minutes** and you will be directed to the Customers Portal.
1. Locate the subscription card that's linked to your personal namespace on GitLab.com, click **Buy more CI minutes**, and complete the details about the transaction. Once we have processed your payment, the extra CI minutes will be synced to your personal namespace.
1. Select **Buy additional minutes** and GitLab redirects you to the Customers Portal.
1. Locate the subscription card that's linked to your personal namespace on GitLab.com, click **Buy more CI minutes**, and complete the details about the transaction. Once we have processed your payment, the extra CI minutes are synced to your personal namespace.
1. To confirm the available CI minutes for your personal projects, click your avatar, then go to **Settings > Usage Quotas**.
The **Additional minutes** displayed now includes the purchased additional CI minutes, plus any minutes rolled over from last month.
@ -287,7 +287,7 @@ To purchase additional minutes for your personal namespace:
Be aware that:
- If you have purchased extra CI minutes before the purchase of a paid plan,
we will calculate a pro-rated charge for your paid plan. That means you may
we calculate a pro-rated charge for your paid plan. That means you may
be charged for less than one year since your subscription was previously
created with the extra CI minutes.
- Once the extra CI minutes have been assigned to a Group, they can't be transferred

2
doc/subscriptions/index.md
View File

@ -152,7 +152,7 @@ With a linked GitLab.com account:
1. Select the desired group from the **This subscription is for** dropdown.
1. Click **Proceed to checkout**.
Subscription charges are calculated based on the total number of users in a group, including its subgroups and nested projects. If the total number of users exceeds the number of seats in your subscription, you will be charged for the additional users.
Subscription charges are calculated based on the total number of users in a group, including its subgroups and nested projects. If the total number of users exceeds the number of seats in your subscription, your account is charged for the additional users.
### Change customer portal account password

26
doc/subscriptions/self_managed/index.md
View File

@ -116,8 +116,8 @@ the contact person who manages your subscription.
It's important to regularly review your user accounts, because:
- A GitLab subscription is based on the number of users. You will pay more than
you should if you renew for too many users, while the renewal will fail if you
- A GitLab subscription is based on the number of users. You pay more than
you should if you renew for too many users, while the renewal fail if you
attempt to renew a subscription for too few users.
- Stale user accounts can be a security risk. A regular review helps reduce this risk.
@ -140,10 +140,10 @@ To add users to a subscription:
1. Select **Add more seats** on the relevant subscription card.
1. Enter the number of additional users.
1. Select **Proceed to checkout**.
1. Review the **Subscription Upgrade Detail**. The system lists the total price for all users on the system and a credit for what you've already paid. You will only be charged for the net change.
1. Review the **Subscription Upgrade Detail**. The system lists the total price for all users on the system and a credit for what you've already paid. You are only be charged for the net change.
1. Select **Confirm Upgrade**.
The following will be emailed to you:
The following items are emailed to you:
- A payment receipt. You can also access this information in the Customers Portal under [**View invoices**](https://customers.gitlab.com/receipts).
- A new license. [Upload this license](../../user/admin_area/license.md#uploading-your-license) to your instance to use it.
@ -165,7 +165,7 @@ We recommend following these steps during renewal:
1. Enter the number of [users over license](#users-over-license) in the second box for the user overage incurred in your previous subscription term.
TIP: **Tip:**
You can find the _users over license_ in your instance's **Admin** dashboard by clicking on the **Admin Area** in the top bar, or going to `/admin`.
You can find the _users over license_ in your instance's **Admin** dashboard by clicking on the **Admin Area** in the top bar, or navigating to `/admin`.
The following table describes details of your admin dashboard and renewal terms:
@ -174,13 +174,13 @@ We recommend following these steps during renewal:
| Users in License | The number of users you've paid for in the current license loaded on the system. This does not include the amount you've paid for `Users over license` during renewal. |
| Active users | The daily count of active users on your system. |
| Maximum users | The highest number of active users on your system during the term of the loaded license. If this number exceeds your users in license count at any point, you incur users over license. |
| Users over license | The number of users that exceed the `Users in License` for the current license term. Charges for this number of users will be incurred at the next renewal. |
| Users over license | The number of users that exceed the `Users in License` for the current license term. Charges for this number of users are incurred at the next renewal. |
1. Review your renewal details and complete the payment process.
1. A license for the renewal term will be available for download on the [Manage Purchases](https://customers.gitlab.com/subscriptions) page on the relevant subscription card. Select **Copy license to clipboard** or **Download license** to get a copy.
1. A license for the renewal term is available for download on the [Manage Purchases](https://customers.gitlab.com/subscriptions) page on the relevant subscription card. Select **Copy license to clipboard** or **Download license** to get a copy.
1. [Upload](../../user/admin_area/license.md#uploading-your-license) your new license to your instance.
An invoice will be generated for the renewal and available for viewing or download on the [View invoices](https://customers.gitlab.com/receipts) page. If you have difficulty during the renewal process, contact our [support team](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=360000071293) for assistance.
An invoice is generated for the renewal and available for viewing or download on the [View invoices](https://customers.gitlab.com/receipts) page. If you have difficulty during the renewal process, contact our [support team](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=360000071293) for assistance.
### Seat Link
@ -197,7 +197,7 @@ Seat Link provides **only** the following information to GitLab:
- Historical maximum user count
- Active users count
For offline or closed network customers, the existing [true-up model](#users-over-license) will be used. Prorated charges are not possible without user count data.
For offline or closed network customers, the existing [true-up model](#users-over-license) is used. Prorated charges are not possible without user count data.
<details>
<summary>Click here to view example content of a Seat Link POST request.</summary>
@ -306,14 +306,14 @@ When your subscription or trial expires, GitLab does not delete your data, but i
may become inaccessible, depending on the tier at expiry. Some features may not
behave as expected if you're not prepared for the expiry. For example,
[environment specific variables not being passed](https://gitlab.com/gitlab-org/gitlab/-/issues/24759).
If you renew or upgrade, your data will again be accessible.
If you renew or upgrade, your data is again accessible.
For self-managed customers, there is a 14-day grace period when your features
will continue to work as-is, after which the entire instance will become read
continue to work as-is, after which the entire instance becomes read
only.
However, if you remove the license, you will immediately revert to Core
features, and the instance will be read / write again.
However, if you remove the license, you immediately revert to Core
features, and the instance become read / write again.
## Customers portal

2
doc/university/training/topics/env_setup.md
View File

@ -12,7 +12,7 @@ comments: false
- **Windows** - Install 'Git for Windows' from [Git for Windows](https://gitforwindows.org).
- **Mac**
- Type '`git`' in the Terminal application.
- If it's not installed, it will prompt you to install it.
- If it's not installed, it prompts you to install it.
- **GNU/Linux** - Enter `which git` in the Terminal application and press <kbd>Enter</kbd> to
determine if Git is installed on your system.

2
doc/university/training/topics/merge_conflicts.md
View File

@ -42,7 +42,7 @@ git commit -am "add line6 and line7"
git push origin master
```
Create a merge request on the GitLab web UI. You'll see a conflict warning.
Create a merge request on the GitLab web UI, and a conflict warning displays.
```shell
git checkout conflicts_branch

2
doc/university/training/topics/stash.md
View File

@ -55,7 +55,7 @@ and we need to change to a different branch.
```
- If we meet conflicts we need to either reset or commit our changes.
- Conflicts through `pop` will not drop a stash afterwards.
- Conflicts through `pop` doesn't drop a stash afterwards.
## Git Stash sample workflow

2
doc/university/training/topics/unstage.md
View File

@ -7,7 +7,7 @@ comments: false
# Unstage
- To remove files from stage use reset HEAD where HEAD is the last commit of the current branch. This will unstage the file but maintain the modifications.
- To remove files from stage use reset HEAD where HEAD is the last commit of the current branch. This unstages the file but maintain the modifications.
```shell
git reset HEAD <file>

4
doc/university/training/user_training.md
View File

@ -46,7 +46,7 @@ Use the tools at your disposal when you get stuck.
- Mac: Type '`git`' in the Terminal application.
> If it's not installed, it will prompt you to install it.
> If it's not installed, it prompts you to install it.
- Debian: '`sudo apt-get install git-all`' or Red Hat '`sudo yum install git-all`'
@ -235,7 +235,7 @@ See GitLab merge requests for examples: <https://gitlab.com/gitlab-org/gitlab-fo
- Useful for marking deployments and releases.
- Annotated tags are an unchangeable part of Git history.
- Soft/lightweight tags can be set and removed at will.
- Soft/lightweight tags can be set and removed at any time.
- Many projects combine an annotated release tag with a stable branch.
- Consider setting deployment/release tags automatically.

4
doc/user/abuse_reports.md
View File

@ -39,7 +39,7 @@ To report abuse from a user's comment:
1. Click the **Send report** button.
NOTE: **Note:**
A URL to the reported user's comment will be pre-filled in the abuse report's
A URL to the reported user's comment is pre-filled in the abuse report's
**Message** field.
## Reporting abuse through a user's issue or merge request
@ -59,7 +59,7 @@ With the **Report abuse** button displayed, to submit an abuse report:
1. Click the **Send report** button.
NOTE: **Note:**
A URL to the reported user's issue or merge request will be pre-filled
A URL to the reported user's issue or merge request is pre-filled
in the abuse report's **Message** field.
## Managing abuse reports

5
doc/user/admin_area/analytics/instance_statistics.md Normal file
View File

@ -0,0 +1,5 @@
---
redirect_to: 'usage_trends.md'
---
This document was moved to [another location](usage_trends.md).

2
doc/user/admin_area/broadcast_messages.md
View File

@ -47,7 +47,7 @@ The available placeholders are:
- `{{username}}`
- `{{instance_id}}`
If the user is not signed in, user related values will be empty.
If the user is not signed in, user related values are empty.
![Broadcast Message Notification](img/broadcast_messages_notification_v12_10.png)

2
doc/user/admin_area/index.md
View File

@ -94,7 +94,7 @@ The list of projects can be sorted by:
A user can choose to hide or show archived projects in the list.
In the **Filter by name** field, type the project name you want to find, and GitLab will filter
In the **Filter by name** field, type the project name you want to find, and GitLab filters
them as you type.
Select from the **Namespace** dropdown to filter only projects in that namespace.

8
doc/user/admin_area/monitoring/health_check.md
View File

@ -70,7 +70,7 @@ The readiness probe checks whether the GitLab instance is ready
to accept traffic via Rails Controllers. The check by default
does validate only instance-checks.
If the `all=1` parameter is specified, the check will also validate
If the `all=1` parameter is specified, the check also validates
the dependent services (Database, Redis, Gitaly etc.)
and gives a status for each.
@ -97,7 +97,7 @@ Example response:
}
```
On failure, the endpoint will return a `503` HTTP status code.
On failure, the endpoint returns a `503` HTTP status code.
This check does hit the database and Redis if authenticated via `token`.
@ -126,7 +126,7 @@ curl 'https://gitlab.example.com/-/liveness'
Example response:
On success, the endpoint will return a `200` HTTP status code, and a response like below.
On success, the endpoint returns a `200` HTTP status code, and a response like below.
```json
{
@ -134,7 +134,7 @@ On success, the endpoint will return a `200` HTTP status code, and a response li
}
```
On failure, the endpoint will return a `503` HTTP status code.
On failure, the endpoint returns a `503` HTTP status code.
This check is being exempt from Rack Attack.

12
doc/user/application_security/index.md
View File

@ -1,6 +1,6 @@
---
stage: none
group: unassigned
stage: secure
group: secure
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
type: reference, howto
---
@ -92,7 +92,7 @@ rules:
## Security Scanning with Auto DevOps
When [Auto DevOps](../../topics/autodevops/) is enabled, all GitLab Security scanning tools will be configured using default settings.
When [Auto DevOps](../../topics/autodevops/) is enabled, all GitLab Security scanning tools are configured using default settings.
- [Auto SAST](../../topics/autodevops/stages.md#auto-sast)
- [Auto Secret Detection](../../topics/autodevops/stages.md#auto-secret-detection)
@ -225,11 +225,11 @@ vulnerability as you learn more over time.
> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.9.
You can dismiss multiple vulnerabilities at once, providing an optional reason.
Selecting the checkboxes on the side of each vulnerability in the list will select that individual vulnerability.
Selecting the checkboxes on the side of each vulnerability in the list selects that individual vulnerability.
Alternatively, you can select all the vulnerabilities in the list by selecting the checkbox in the table header.
Deselecting the checkbox in the header will deselect all the vulnerabilities in the list.
Deselecting the checkbox in the header deselects all the vulnerabilities in the list.
Once you have selected some vulnerabilities, a menu appears at the top of the table that allows you to select a dismissal reason.
Pressing the "Dismiss Selected" button will dismiss all the selected vulnerabilities at once, with the reason you chose.
Pressing the "Dismiss Selected" button dismisses all the selected vulnerabilities at once, with the reason you chose.
![Multiple vulnerability dismissal](img/multi_select_v12_9.png)

2
doc/user/feature_highlight.md
View File

@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/16379) in GitLab 10.5
Feature highlights are represented by a pulsing blue dot. Hovering over the dot
will display more information.
displays more information.
They are used to emphasize a certain feature and make something more visible to the user.
You can dismiss any feature highlight permanently by clicking the "Got it" link

20
doc/user/gitlab_com/index.md
View File

@ -6,13 +6,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# GitLab.com settings
In this page you will find information about the settings that are used on
This page contains information about the settings that are used on
[GitLab.com](https://about.gitlab.com/pricing/).
## SSH host keys fingerprints
Below are the fingerprints for GitLab.com's SSH host keys. The first time you connect
to a GitLab.com repository, you'll see one of these keys in the output.
to a GitLab.com repository, one of these keys is displayed in the output.
| Algorithm | MD5 (deprecated) | SHA256 |
| --------- | --- | ------- |
@ -50,7 +50,7 @@ Projects can be backed up in their entirety by exporting them either [through th
With exports, be sure to take note of [what is and is not](../project/settings/import_export.md#exported-contents), included in a project export.
Since GitLab is built on Git, you can back up **just** the repository of a project by [cloning](../../gitlab-basics/start-using-git.md#clone-a-repository) it to another machine. Similarly, if you need to back up just the wiki of a repository it can also be cloned and all files uploaded to that wiki will come with it [if they were uploaded after 2020-08-22](../project/wiki/index.md#creating-a-new-wiki-page).
Since GitLab is built on Git, you can back up **just** the repository of a project by [cloning](../../gitlab-basics/start-using-git.md#clone-a-repository) it to another machine. Similarly, if you need to back up just the wiki of a repository it can also be cloned and all files uploaded to that wiki are included [if they were uploaded after 2020-08-22](../project/wiki/index.md#creating-a-new-wiki-page).
## Alternative SSH port
@ -161,10 +161,10 @@ installed. Instances provide 1 vCPU and 25GB of HDD disk space. The default
region of the VMs is US East1.
Each instance is used only for one job, this ensures any sensitive data left on the system can't be accessed by other people their CI jobs.
The `gitlab-shared-runners-manager-X.gitlab.com` fleet of runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They will not run untagged jobs and unlike the general fleet of shared runners, the instances are re-used up to 40 times.
The `gitlab-shared-runners-manager-X.gitlab.com` fleet of runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They don't run untagged jobs and unlike the general fleet of shared runners, the instances are re-used up to 40 times.
Jobs handled by the shared runners on GitLab.com (`shared-runners-manager-X.gitlab.com`),
**will be timed out after 3 hours**, regardless of the timeout configured in a
**time out after 3 hours**, regardless of the timeout configured in a
project. Check the issues [4010](https://gitlab.com/gitlab-com/infrastructure/-/issues/4010) and [4070](https://gitlab.com/gitlab-com/infrastructure/-/issues/4070) for the reference.
Below are the shared runners settings.
@ -396,19 +396,19 @@ test:
- The average provisioning time for a new Windows VM is 5 minutes.
This means that you may notice slower build start times
on the Windows shared runner fleet during the beta. In a future
release we will update the autoscaler to enable
the pre-provisioning of virtual machines. This will significantly reduce
release we intend to update the autoscaler to enable
the pre-provisioning of virtual machines. This is intended to significantly reduce
the time it takes to provision a VM on the Windows fleet. You can
follow along in the [related issue](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/-/issues/32).
- The Windows shared runner fleet may be unavailable occasionally
for maintenance or updates.
- The Windows shared runner virtual machine instances do not use the
GitLab Docker executor. This means that you will not be able to specify
GitLab Docker executor. This means that you can't specify
[`image`](../../ci/yaml/README.md#image) or [`services`](../../ci/yaml/README.md#services) in
your pipeline configuration.
- For the beta release, we have included a set of software packages in
the base VM image. If your CI job requires additional software that's
not included in this list, then you will need to add installation
not included in this list, then you must add installation
commands to [`before_script`](../../ci/yaml/README.md#before_script) or [`script`](../../ci/yaml/README.md#script) to install the required
software. Note that each job runs on a new VM instance, so the
installation of additional software packages needs to be repeated for
@ -512,7 +512,7 @@ documentation.
IP blocks usually happen when GitLab.com receives unusual traffic from a single
IP address that the system views as potentially malicious based on rate limit
settings. After the unusual traffic ceases, the IP address will be automatically
settings. After the unusual traffic ceases, the IP address is automatically
released depending on the type of block, as described below.
If you receive a `403 Forbidden` error for all requests to GitLab.com, please

31
doc/user/group/iterations/index.md
View File

@ -76,12 +76,7 @@ To view an iteration report, go to the iterations list page and click an iterati
### Iteration burndown and burnup charts
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/222750) in [GitLab Starter](https://about.gitlab.com/pricing/) 13.5.
> - It was deployed behind a feature flag, disabled by default.
> - [Became enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/45492) on GitLab 13.6.
> - It's enabled on GitLab.com.
> - It's able to be enabled or disabled per-group.
> - It's recommended for production use.
> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#disable-iteration-charts). **(STARTER ONLY)**
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/269972) in [GitLab Starter](https://about.gitlab.com/pricing/) 13.7.
The iteration report includes [burndown and burnup charts](../../project/milestones/burndown_and_burnup_charts.md),
similar to how they appear when viewing a [milestone](../../project/milestones/index.md).
@ -113,30 +108,6 @@ Feature.disable(:group_iterations)
Feature.disable(:group_iterations, Group.find(<group ID>))
```
## Disable iteration charts **(STARTER ONLY)**
GitLab iteration charts feature is deployed with a feature flag that is **enabled by default**.
[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
can disable it for your instance. `:iteration_charts` can be enabled or disabled per-group.
To enable it:
```ruby
# Instance-wide
Feature.enable(:iteration_charts)
# or by group
Feature.enable(:iteration_charts, Group.find(<group ID>))
```
To disable it:
```ruby
# Instance-wide
Feature.disable(:iteration_charts)
# or by group
Feature.disable(:iteration_charts, Group.find(<group ID>))
```
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues

6
doc/user/group/subgroups/index.md
View File

@ -109,7 +109,7 @@ To create a subgroup:
![Subgroups page](img/create_new_group.png)
1. Click the **Create group** button and you will be taken to the new group's
1. Click the **Create group** button to be redirected to the new group's
dashboard page.
Follow the same process to create any subsequent groups.
@ -170,10 +170,10 @@ To override a user's membership of an ancestor group (the first group they were
added to), add the user to the new subgroup again with a higher set of permissions.
For example, if User0 was first added to group `group-1/group-1-1` with Developer
permissions, then they will inherit those permissions in every other subgroup
permissions, then they inherit those permissions in every other subgroup
of `group-1/group-1-1`. To give them Maintainer access to `group-1/group-1-1/group1-1-1`,
you would add them again in that group as Maintainer. Removing them from that group,
the permissions will fallback to those of the ancestor group.
the permissions fall back to those of the ancestor group.
## Mentioning subgroups

4
doc/user/index.md
View File

@ -10,7 +10,7 @@ description: 'Read through the GitLab User documentation to learn how to use, co
Welcome to GitLab! We're glad to have you here!
As a GitLab user you'll have access to all the features
As a GitLab user you have access to all the features
your [subscription](https://about.gitlab.com/pricing/)
includes, except [GitLab administrator](../administration/index.md)
settings, unless you have admin privileges to install, configure,
@ -175,7 +175,7 @@ such as Trello, Jira, etc.
## Webhooks
Configure [webhooks](project/integrations/webhooks.md) to listen for
specific events like pushes, issues or merge requests. GitLab will send a
specific events like pushes, issues or merge requests. GitLab sends a
POST request with data to the webhook URL.
## API

2
doc/user/instance/clusters/index.md
View File

@ -18,7 +18,7 @@ The instance level Kubernetes clusters can be found in the top menu by navigatin
## Cluster precedence
GitLab will try to match clusters in the following order:
GitLab tries to match clusters in the following order:
- Project-level clusters.
- Group-level clusters.

4
doc/user/operations_dashboard/index.md
View File

@ -26,7 +26,7 @@ To add a project to the dashboard:
1. Search and add one or more projects using the **Search your projects** field.
1. Click the **Add projects** button.
Once added, the dashboard will display the project's number of active alerts,
Once added, the dashboard displays the project's number of active alerts,
last commit, pipeline status, and when it was last deployed.
The Operations and [Environments](../../ci/environments/environments_dashboard.md) dashboards share the same list of projects. Adding or removing a project from one adds or removes the project from the other.
@ -35,7 +35,7 @@ The Operations and [Environments](../../ci/environments/environments_dashboard.m
## Arranging projects on a dashboard
You can drag project cards to change their order. The card order is currently only saved to your browser, so will not change the dashboard for other people.
You can drag project cards to change their order. The card order is currently only saved to your browser, so it doesn't change the dashboard for other people.
## Making it the default dashboard when you sign in

2
doc/user/profile/active_sessions.md
View File

@ -34,7 +34,7 @@ exceeds 100, the oldest ones are deleted.
NOTE: **Note:**
When any session is revoked all **Remember me** tokens for all
devices will be revoked. See ['Why do I keep getting signed out?'](index.md#why-do-i-keep-getting-signed-out)
devices are revoked. See ['Why do I keep getting signed out?'](index.md#why-do-i-keep-getting-signed-out)
for more information about the **Remember me** feature.
<!-- ## Troubleshooting

6
doc/user/profile/preferences.md
View File

@ -107,8 +107,8 @@ While `1280px` is the standard max width when using fixed layout, some pages sti
For users who have access to a large number of projects but only keep up with a
select few, the amount of activity on the default Dashboard page can be
overwhelming. Changing this setting allows you to redefine what your default
dashboard will be.
overwhelming. Changing this setting allows you to redefine your default
dashboard.
You have 8 options here that you can use for your default dashboard view:
@ -164,7 +164,7 @@ You can choose one of the following options as the first day of the week:
- Sunday
- Monday
If you select **System Default**, the system-wide default setting will be used.
If you select **System Default**, the system-wide default setting is used.
## Integrations

6
doc/user/project/canary_deployments.md
View File

@ -32,13 +32,13 @@ deployments right inside the [Deploy Board](deploy_boards.md), without the need
Canary deployments can be used when you want to ship features to only a portion of
your pods fleet and watch their behavior as a percentage of your user base
visits the temporarily deployed feature. If all works well, you can deploy the
feature to production knowing that it won't cause any problems.
feature to production knowing that it shouldn't cause any problems.
Canary deployments are also especially useful for backend refactors, performance
improvements, or other changes where the user interface doesn't change, but you
want to make sure the performance stays the same, or improves. Developers need
to be careful when using canaries with user-facing changes, because by default,
requests from the same user will be randomly distributed between canary and
requests from the same user are randomly distributed between canary and
non-canary pods, which could result in confusion or even errors. If needed, you
may want to consider [setting `service.spec.sessionAffinity` to `ClientIP` in
your Kubernetes service definitions](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies), but that is beyond the scope of
@ -60,7 +60,7 @@ This allows GitLab to discover whether a deployment is stable or canary (tempora
Once all of the above are set up and the pipeline has run at least once,
navigate to the environments page under **Pipelines > Environments**.
As the pipeline executes Deploy Boards will clearly mark canary pods, enabling
As the pipeline executes, Deploy Boards clearly mark canary pods, enabling
quick and easy insight into the status of each environment and deployment.
Canary deployments are marked with a yellow dot in the Deploy Board so that you

2
doc/user/project/import/tfvc.md
View File

@ -38,7 +38,7 @@ Advantages of migrating to Git/GitLab:
- **No licensing costs:** Git is open source, while TFVC is proprietary.
- **Shorter learning curve:** Git has a big community and a vast number of
tutorials to get you started (see our [Git topic](../../../topics/git/index.md)).
- **Integration with modern tools:** After migrating to Git and GitLab, you will have
- **Integration with modern tools:** After migrating to Git and GitLab, you have
an open source, end-to-end software development platform with built-in version
control, issue tracking, code review, CI/CD, and more.

43
doc/user/project/insights/index.md
View File

@ -27,19 +27,19 @@ link in the left sidebar:
## Configure your Insights
Insights are configured using a YAML file called `.gitlab/insights.yml` within
a project. That file will then be used in the project's Insights page.
a project. That file is used in the project's Insights page.
See [Writing your `.gitlab/insights.yml`](#writing-your-gitlabinsightsyml) below
for details about the content of this file.
NOTE: **Note:**
Once the configuration file is created, you can also
After the configuration file is created, you can also
[use it for your project's group](../../group/insights/index.md#configure-your-insights).
NOTE: **Note:**
If the project doesn't have any configuration file, it'll try to use
If the project doesn't have any configuration file, it attempts to use
the group configuration if possible. If the group doesn't have any
configuration, the default configuration will be used.
configuration, the default configuration is used.
## Permissions
@ -56,11 +56,11 @@ You may also consult the [group permissions table](../../permissions.md#group-me
## Writing your `.gitlab/insights.yml`
The `.gitlab/insights.yml` file defines the structure and order of the Insights
charts that will be displayed in each Insights page of your project or group.
charts displayed in each Insights page of your project or group.
Each page has a unique key and a collection of charts to fetch and display.
For example, here's a single definition for Insights that will display one page with one chart:
For example, here's a single definition for Insights that displays one page with one chart:
```yaml
bugsCharts:
@ -103,8 +103,8 @@ The following table lists available parameters for charts:
| Keyword | Description |
|:---------------------------------------------------|:------------|
| [`title`](#title) | The title of the chart. This will displayed on the Insights page. |
| [`description`](#description) | A description for the individual chart. This will be displayed above the relevant chart. |
| [`title`](#title) | The title of the chart. This displays on the Insights page. |
| [`description`](#description) | A description for the individual chart. This displays above the relevant chart. |
| [`type`](#type) | The type of chart: `bar`, `line` or `stacked-bar`. |
| [`query`](#query) | A hash that defines the conditions for issues / merge requests to be part of the chart. |
@ -115,7 +115,7 @@ Insights charts.
### `title`
`title` is the title of the chart as it will be displayed on the Insights page.
`title` is the title of the chart as it displays on the Insights page.
For example:
```yaml
@ -187,14 +187,14 @@ Defines the type of "issuable" you want to create a chart for.
Supported values are:
- `issue`: The chart will display issues' data.
- `merge_request`: The chart will display merge requests' data.
- `issue`: The chart displays issues' data.
- `merge_request`: The chart displays merge requests' data.
#### `query.issuable_state`
Filter by the state of the queried "issuable".
By default, the `opened` state filter will be applied.
By default, the `opened` state filter is applied.
Supported values are:
@ -208,7 +208,7 @@ Supported values are:
Filter by labels applied to the queried "issuable".
By default, no labels filter will be applied. All the defined labels must be
By default, no labels filter is applied. All the defined labels must be
applied to the "issuable" in order for it to be selected.
Example:
@ -229,7 +229,7 @@ monthlyBugsCreated:
Group "issuable" by the configured labels.
By default, no grouping will be done. When using this keyword, you need to
By default, no grouping is done. When using this keyword, you need to
set `type` to either `line` or `stacked-bar`.
Example:
@ -268,7 +268,7 @@ The unit is related to the `query.group_by` you defined. For instance if you
defined `query.group_by: 'day'` then `query.period_limit: 365` would mean
"Gather and display data for the last 365 days".
By default, default values will be applied depending on the `query.group_by`
By default, default values are applied depending on the `query.group_by`
you defined.
| `query.group_by` | Default value |
@ -294,9 +294,8 @@ The `period_field` is automatically set to:
- `created_at` otherwise
NOTE: **Note:**
Until [this bug](https://gitlab.com/gitlab-org/gitlab/-/issues/26911), is resolved, you may see `created_at`
in place of `merged_at`.
`created_at` will be used instead.
Until [this bug](https://gitlab.com/gitlab-org/gitlab/-/issues/26911), is resolved,
you may see `created_at` in place of `merged_at`. `created_at` is used instead.
### `projects`
@ -304,22 +303,22 @@ in place of `merged_at`.
You can limit where the "issuables" can be queried from:
- If `.gitlab/insights.yml` is used for a [group's insights](../../group/insights/index.md#configure-your-insights), with `projects`, you can limit the projects to be queried. By default, all projects under the group will be used.
- If `.gitlab/insights.yml` is used for a project's insights, specifying any other projects will yield no results. By default, the project itself will be used.
- If `.gitlab/insights.yml` is used for a [group's insights](../../group/insights/index.md#configure-your-insights), with `projects`, you can limit the projects to be queried. By default, all projects under the group are used.
- If `.gitlab/insights.yml` is used for a project's insights, specifying any other projects yields no results. By default, the project itself is used.
#### `projects.only`
The `projects.only` option specifies the projects which the "issuables"
should be queried from.
Projects listed here will be ignored when:
Projects listed here are ignored when:
- They don't exist.
- The current user doesn't have sufficient permissions to read them.
- They are outside of the group.
In the following `insights.yml` example, we specify the projects
the queries will be used on. This example is useful when setting
the queries are used on. This example is useful when setting
a group's insights:
```yaml

8
doc/user/project/issues/csv_export.md
View File

@ -35,11 +35,11 @@ Among numerous use cases for exporting issues for CSV, we can name a few:
## Choosing which issues to include
After selecting a project, from the issues page you can narrow down which issues to export using the search bar, along with the All/Open/Closed tabs. All issues returned will be exported, including those not shown on the first page.
After selecting a project, from the issues page you can narrow down which issues to export using the search bar, along with the All/Open/Closed tabs. All issues returned are exported, including those not shown on the first page.
![CSV export button](img/csv_export_button_v12_9.png)
You will be asked to confirm the number of issues and email address for the export, after which the email will begin being prepared.
GitLab asks you to confirm the number of issues and email address for the export, after which the email is prepared.
![CSV export modal dialog](img/csv_export_modal.png)
@ -53,7 +53,7 @@ Exported issues are always sorted by `Issue ID`.
>
> **Weight** and **Locked** columns were [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/5300) in GitLab Starter 10.8.
Data will be encoded with a comma as the column delimiter, with `"` used to quote fields if needed, and newlines to separate rows. The first row will be the headers, which are listed in the following table along with a description of the values:
Data wis encoded with a comma as the column delimiter, with `"` used to quote fields if needed, and newlines to separate rows. The first row contains the headers, which are listed in the following table along with a description of the values:
| Column | Description |
|---------|-------------|
@ -82,4 +82,4 @@ Data will be encoded with a comma as the column delimiter, with `"` used to quot
## Limitations
- Export Issues to CSV is not available at the Group's Issues List.
- As the issues will be sent as an email attachment, there is a limit on how much data can be exported. Currently this limit is 15MB to ensure successful delivery across a range of email providers. If this limit is reached we suggest narrowing the search before export, perhaps by exporting open and closed issues separately.
- As the issues are sent as an email attachment, there is a limit on how much data can be exported. Currently this limit is 15MB to ensure successful delivery across a range of email providers. If this limit is reached we suggest narrowing the search before export, perhaps by exporting open and closed issues separately.

2
doc/user/project/issues/csv_import.md
View File

@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
Issues can be imported to a project by uploading a CSV file with the columns
`title` and `description`.
The user uploading the CSV file will be set as the author of the imported issues.
The user uploading the CSV file is set as the author of the imported issues.
NOTE: **Note:**
A permission level of [Developer](../../permissions.md), or higher, is required

6
doc/user/project/members/index.md
View File

@ -53,7 +53,7 @@ that you'd like to give the user. Note that you can select more than one user.
![Give user permissions](img/add_user_give_permissions.png)
Once done, hit **Add users to project** and they will be immediately added to
Once done, select **Add users to project** and they are immediately added to
your project with the permissions you gave them above.
![List members](img/add_user_list_members.png)
@ -71,7 +71,7 @@ In the dropdown menu, you can see only the projects you are Maintainer on.
![Import members from another project](img/add_user_import_members_from_another_project.png)
Select the one you want and hit **Import project members**. A flash message
notifying you that the import was successful will appear, and the new members
displays, notifying you that the import was successful, and the new members
are now in the project's members list. Notice that the permissions that they
had on the project you imported from are retained.
@ -96,7 +96,7 @@ invitation, change their access level, or even delete them.
![Invite user members list](img/add_user_email_accept.png)
Once the user accepts the invitation, they will be prompted to create a new
After the user accepts the invitation, they are prompted to create a new
GitLab account using the same e-mail address the invitation was sent to.
Note: **Note:**

6
doc/user/project/members/share_project_with_groups.md
View File

@ -34,7 +34,7 @@ To share 'Project Acme' with the 'Engineering' group:
![share project with groups tab](img/share_project_with_groups_tab.png)
1. After sharing 'Project Acme' with 'Engineering', the project will be listed
1. After sharing 'Project Acme' with 'Engineering', the project is listed
on the group dashboard
!['Project Acme' is listed as a shared project for 'Engineering'](img/other_group_sees_shared_project.png)
@ -48,11 +48,11 @@ Admins are able to share projects with any group in the system.
## Maximum access level
In the example above, the maximum access level of 'Developer' for members from 'Engineering' means that users with higher access levels in 'Engineering' ('Maintainer' or 'Owner') will only have 'Developer' access to 'Project Acme'.
In the example above, the maximum access level of 'Developer' for members from 'Engineering' means that users with higher access levels in 'Engineering' ('Maintainer' or 'Owner') only have 'Developer' access to 'Project Acme'.
## Sharing public project with private group
When sharing a public project with a private group, owners and maintainers of the project will see the name of the group in the `members` page. Owners will also have the possibility to see members of the private group they don't have access to when mentioning them in the issue or merge request.
When sharing a public project with a private group, owners and maintainers of the project see the name of the group in the `members` page. Owners also have the possibility to see members of the private group they don't have access to when mentioning them in the issue or merge request.
## Share project with group lock

10
doc/user/project/merge_requests/versions.md
View File

@ -22,8 +22,8 @@ can select an older one from version dropdown.
![Merge request versions dropdown](img/versions_dropdown.png)
Merge request versions are based on push not on commit. So, if you pushed 5
commits in a single push, it will be a single option in the dropdown. If you
pushed 5 times, that will count for 5 options.
commits in a single push, it displays as a single option in the dropdown. If you
pushed 5 times, that counts for 5 options.
You can also compare the merge request version with an older one to see what has
changed since then.
@ -42,12 +42,12 @@ changes appears as a system note.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/2383) in GitLab 10.5.
When viewing the commit details page, GitLab will link to the merge request (or
When viewing the commit details page, GitLab links to the merge request (or
merge requests, if it's in more than one) containing that commit.
This only applies to commits that are in the most recent version of a merge
request - if a commit was in a merge request, then rebased out of that merge
request, they will not be linked.
request - if commits were in a merge request, then rebased out of that merge
request, they aren't linked.
## `HEAD` comparison mode for Merge Requests

27
doc/user/project/milestones/burndown_and_burnup_charts.md
View File

@ -104,13 +104,7 @@ Reopened issues are considered as having been opened on the day after they were
## Burnup charts
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/6903) in [GitLab Starter](https://about.gitlab.com/pricing/) 13.6.
> - It's [deployed behind a feature flag](../../feature_flags.md), enabled by default.
> - It's enabled on GitLab.com.
> - It's recommended for production use.
> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-burnup-charts). **(STARTER ONLY)**
CAUTION: **Warning:**
This feature might not be available to you. Check the **version history** note above for details.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/268350) in [GitLab Starter](https://about.gitlab.com/pricing/) 13.7.
Burnup charts show the assigned and completed work for a milestone.
@ -136,25 +130,6 @@ Burnup charts can show either the total number of issues or total weight for eac
day of the milestone. Use the toggle above the charts to switch between total
and weight.
### Enable or disable burnup charts **(STARTER ONLY)**
Burnup charts is under development but ready for production use.
It is deployed behind a feature flag that is **enabled by default**.
[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
can opt to disable it.
To enable it:
```ruby
Feature.enable(:burnup_charts)
```
To disable it:
```ruby
Feature.disable(:burnup_charts)
```
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues

6
doc/user/shortcuts.md
View File

@ -54,7 +54,7 @@ other keyboard shortcuts are disabled as explained above.
## Project
These shortcuts are available from any page within a project. You must type them
relatively quickly to work, and they will take you to another page in the project.
relatively quickly to work, and they take you to another page in the project.
| Keyboard Shortcut | Description |
| --------------------------- | ----------- |
@ -87,7 +87,7 @@ These shortcuts are available when viewing issues and merge requests.
| <kbd>a</kbd> | Change assignee. |
| <kbd>m</kbd> | Change milestone. |
| <kbd>l</kbd> | Change label. |
| <kbd>r</kbd> | Start writing a comment. If any text is selected, it will be quoted in the comment. Can't be used to reply within a thread. |
| <kbd>r</kbd> | Start writing a comment. If any text is selected, it is quoted in the comment. Can't be used to reply within a thread. |
| <kbd>n</kbd> | Move to next unresolved discussion (merge requests only). |
| <kbd>p</kbd> | Move to previous unresolved discussion (merge requests only). |
| <kbd>]</kbd> or <kbd>j</kbd> | Move to next file (merge requests only). |
@ -153,6 +153,6 @@ These shortcuts are available when viewing [Epics](group/epics/index.md):
| Keyboard Shortcut | Description |
| ----------------- | ----------- |
| <kbd>r</kbd> | Start writing a comment. If any text is selected, it will be quoted in the comment. Can't be used to reply within a thread. |
| <kbd>r</kbd> | Start writing a comment. If any text is selected, it is quoted in the comment. Can't be used to reply within a thread. |
| <kbd>e</kbd> | Edit description. |
| <kbd>l</kbd> | Change label. |

8
doc/user/upgrade_email_bypass.md
View File

@ -27,7 +27,7 @@ sent within five minutes, with a link for users to re-confirm the subject email
## Do the confirmation emails expire?
The links in these re-confirmation emails expire after one day by default. Users who click an expired link will be asked to request a new re-confirmation email. Any user can request a new re-confirmation email from `http://gitlab.example.com/users/confirmation/new`.
The links in these re-confirmation emails expire after one day by default. Users who click an expired link are asked to request a new re-confirmation email. Any user can request a new re-confirmation email from `http://gitlab.example.com/users/confirmation/new`.
## Generate a list of affected users
@ -112,16 +112,16 @@ The command described in this section may activate users who have not properly c
## What about LDAP users?
LDAP Users will remain confirmed if all of the following conditions are met:
LDAP Users remain confirmed if all of the following conditions are met:
- The ["User email confirmation at sign-up" option](../security/user_email_confirmation.md) is set to false.
- The first sign-in is based on user LDAP credentials.
- The user has added and verified [a secondary email address](profile/index.md#profile-settings) some time later.
NOTE: **Note:**
Confirmation timestamps (primary vs. secondary) will be different.
Confirmation timestamps (primary vs. secondary) are different.
Users will be unconfirmed by the background migration if any of the following conditions are met:
Users remain unconfirmed by the background migration if any of the following conditions are met:
- They [create an account through GitLab](profile/account/create_accounts.md).
- They [swap their primary email address](profile/index.md#profile-settings) and verify it.

2
spec/factories/sent_notifications.rb
View File

@ -4,7 +4,7 @@ FactoryBot.define do
factory :sent_notification do
project
recipient { project.creator }
noteable { create(:issue, project: project) }
noteable { association(:issue, project: project) }
reply_key { SentNotification.reply_key }
end
end

4
spec/finders/issues_finder_spec.rb
View File

@ -472,10 +472,6 @@ RSpec.describe IssuesFinder do
it 'returns issues with title and description match for search term' do
expect(issues).to contain_exactly(issue1, issue2)
end
it 'uses optimizer hints' do
expect(issues.to_sql).to match(/BitmapScan/)
end
end
context 'filtering by issue term in title' do