diff --git a/.gitlab/issue_templates/Security Release Tracking Issue.md b/.gitlab/issue_templates/Security Release Tracking Issue.md deleted file mode 100644 index fce68d61204..00000000000 --- a/.gitlab/issue_templates/Security Release Tracking Issue.md +++ /dev/null @@ -1,41 +0,0 @@ - - -: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}
-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 diff --git a/.rubocop_manual_todo.yml b/.rubocop_manual_todo.yml index 83402ff25b1..2c36a444f70 100644 --- a/.rubocop_manual_todo.yml +++ b/.rubocop_manual_todo.yml @@ -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' diff --git a/app/controllers/groups/milestones_controller.rb b/app/controllers/groups/milestones_controller.rb index 03d41f1dd6d..84dc570a1e9 100644 --- a/app/controllers/groups/milestones_controller.rb +++ b/app/controllers/groups/milestones_controller.rb @@ -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 diff --git a/app/controllers/projects/milestones_controller.rb b/app/controllers/projects/milestones_controller.rb index 31189c888b7..dcd3c49441e 100644 --- a/app/controllers/projects/milestones_controller.rb +++ b/app/controllers/projects/milestones_controller.rb @@ -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! diff --git a/app/finders/issuable_finder.rb b/app/finders/issuable_finder.rb index d431c3e3699..922b53b514d 100644 --- a/app/finders/issuable_finder.rb +++ b/app/finders/issuable_finder.rb @@ -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?) diff --git a/changelogs/unreleased/239177_add_checksum_into_vulnerability_remediations.yml b/changelogs/unreleased/239177_add_checksum_into_vulnerability_remediations.yml new file mode 100644 index 00000000000..b65644379ec --- /dev/null +++ b/changelogs/unreleased/239177_add_checksum_into_vulnerability_remediations.yml @@ -0,0 +1,5 @@ +--- +title: Add `checksum` column into the `vulnerability_remediations` table +merge_request: 48165 +author: +type: changed diff --git a/config/feature_flags/development/burnup_charts.yml b/config/feature_flags/development/burnup_charts.yml deleted file mode 100644 index 3fcc0b33b3f..00000000000 --- a/config/feature_flags/development/burnup_charts.yml +++ /dev/null @@ -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 diff --git a/config/feature_flags/development/pg_hint_plan_for_issuables.yml b/config/feature_flags/development/pg_hint_plan_for_issuables.yml deleted file mode 100644 index 06d20c404c5..00000000000 --- a/config/feature_flags/development/pg_hint_plan_for_issuables.yml +++ /dev/null @@ -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 diff --git a/db/migrate/20201119164605_add_checksum_into_vulnerability_remediations.rb b/db/migrate/20201119164605_add_checksum_into_vulnerability_remediations.rb new file mode 100644 index 00000000000..a9ac1ed0676 --- /dev/null +++ b/db/migrate/20201119164605_add_checksum_into_vulnerability_remediations.rb @@ -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 diff --git a/db/schema_migrations/20201119164605 b/db/schema_migrations/20201119164605 new file mode 100644 index 00000000000..61e4c88a241 --- /dev/null +++ b/db/schema_migrations/20201119164605 @@ -0,0 +1 @@ +5abd2cfdf96b493f8d3ecc857f850acb95e3ea30307a72c2e6f20c5feff8f5e7 \ No newline at end of file diff --git a/db/structure.sql b/db/structure.sql index 6b812881e2d..d65c1a3dd35 100644 --- a/db/structure.sql +++ b/db/structure.sql @@ -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); diff --git a/doc/architecture/blueprints/cloud_native_build_logs/index.md b/doc/architecture/blueprints/cloud_native_build_logs/index.md index 27b7a8ffae3..f69eb6714d3 100644 --- a/doc/architecture/blueprints/cloud_native_build_logs/index.md +++ b/doc/architecture/blueprints/cloud_native_build_logs/index.md @@ -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 diff --git a/doc/architecture/blueprints/cloud_native_gitlab_pages/index.md b/doc/architecture/blueprints/cloud_native_gitlab_pages/index.md index 27d2f1362e5..cf39c1fd241 100644 --- a/doc/architecture/blueprints/cloud_native_gitlab_pages/index.md +++ b/doc/architecture/blueprints/cloud_native_gitlab_pages/index.md @@ -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 diff --git a/doc/architecture/blueprints/image_resizing/index.md b/doc/architecture/blueprints/image_resizing/index.md index 47e2ad24960..bb68bee6753 100644 --- a/doc/architecture/blueprints/image_resizing/index.md +++ b/doc/architecture/blueprints/image_resizing/index.md @@ -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 diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md index 9356e9f4614..10a1917d791 100644 --- a/doc/ci/triggers/README.md +++ b/doc/ci/triggers/README.md @@ -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. diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index e323da3ff28..77684576154 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -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: diff --git a/doc/development/new_fe_guide/development/performance.md b/doc/development/new_fe_guide/development/performance.md index 44f5bccde95..7a5da941a68 100644 --- a/doc/development/new_fe_guide/development/performance.md +++ b/doc/development/new_fe_guide/development/performance.md @@ -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: diff --git a/doc/integration/cas.md b/doc/integration/cas.md index e61988c3301..6b8da8ecbd5 100644 --- a/doc/integration/cas.md +++ b/doc/integration/cas.md @@ -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. diff --git a/doc/integration/jenkins.md b/doc/integration/jenkins.md index 7eb147c1fe6..9fd82c22e8f 100644 --- a/doc/integration/jenkins.md +++ b/doc/integration/jenkins.md @@ -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 diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md index a06fe00ef0d..32b7f18c840 100644 --- a/doc/raketasks/backup_restore.md +++ b/doc/raketasks/backup_restore.md @@ -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 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. diff --git a/doc/raketasks/import.md b/doc/raketasks/import.md index ecd777361a7..a0d8fd0a68b 100644 --- a/doc/raketasks/import.md +++ b/doc/raketasks/import.md @@ -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: diff --git a/doc/raketasks/user_management.md b/doc/raketasks/user_management.md index a0a880eac51..d40516bae18 100644 --- a/doc/raketasks/user_management.md +++ b/doc/raketasks/user_management.md @@ -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 `` value can be read from `config/secrets.yml` (`` 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. diff --git a/doc/subscriptions/gitlab_com/index.md b/doc/subscriptions/gitlab_com/index.md index a03c8e758de..2a35898b5fd 100644 --- a/doc/subscriptions/gitlab_com/index.md +++ b/doc/subscriptions/gitlab_com/index.md @@ -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 diff --git a/doc/subscriptions/index.md b/doc/subscriptions/index.md index df71c6bcf31..e476618dc1b 100644 --- a/doc/subscriptions/index.md +++ b/doc/subscriptions/index.md @@ -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 diff --git a/doc/subscriptions/self_managed/index.md b/doc/subscriptions/self_managed/index.md index a63c2830909..821d15c0b3a 100644 --- a/doc/subscriptions/self_managed/index.md +++ b/doc/subscriptions/self_managed/index.md @@ -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.
Click here to view example content of a Seat Link POST request. @@ -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 diff --git a/doc/university/training/topics/env_setup.md b/doc/university/training/topics/env_setup.md index cbe2ce46be4..f616ad4e49f 100644 --- a/doc/university/training/topics/env_setup.md +++ b/doc/university/training/topics/env_setup.md @@ -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 Enter to determine if Git is installed on your system. diff --git a/doc/university/training/topics/merge_conflicts.md b/doc/university/training/topics/merge_conflicts.md index 87cb119768f..38cc14d4593 100644 --- a/doc/university/training/topics/merge_conflicts.md +++ b/doc/university/training/topics/merge_conflicts.md @@ -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 diff --git a/doc/university/training/topics/stash.md b/doc/university/training/topics/stash.md index db4a21da6ba..393f0490b83 100644 --- a/doc/university/training/topics/stash.md +++ b/doc/university/training/topics/stash.md @@ -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 diff --git a/doc/university/training/topics/unstage.md b/doc/university/training/topics/unstage.md index 77aca3cdab8..4f0ac3652a7 100644 --- a/doc/university/training/topics/unstage.md +++ b/doc/university/training/topics/unstage.md @@ -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 diff --git a/doc/university/training/user_training.md b/doc/university/training/user_training.md index 86f397eba41..90c10339c6c 100644 --- a/doc/university/training/user_training.md +++ b/doc/university/training/user_training.md @@ -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: 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) diff --git a/doc/user/feature_highlight.md b/doc/user/feature_highlight.md index 31eb0e6375d..0e57ffb0813 100644 --- a/doc/user/feature_highlight.md +++ b/doc/user/feature_highlight.md @@ -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 diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md index 54f14c71c93..26e02c520dc 100644 --- a/doc/user/gitlab_com/index.md +++ b/doc/user/gitlab_com/index.md @@ -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 diff --git a/doc/user/group/iterations/index.md b/doc/user/group/iterations/index.md index 90050e217ee..e650dbcae45 100644 --- a/doc/user/group/iterations/index.md +++ b/doc/user/group/iterations/index.md @@ -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()) ``` -## 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()) -``` - -To disable it: - -```ruby -# Instance-wide -Feature.disable(:iteration_charts) -# or by group -Feature.disable(:iteration_charts, Group.find()) -``` -