Add latest changes from gitlab-org/gitlab@master

app/finders/deployments_finder.rb

+# frozen_string_literal: true
+
+class DeploymentsFinder
+  attr_reader :project, :params
+
+  ALLOWED_SORT_VALUES = %w[id iid created_at updated_at ref].freeze
+  DEFAULT_SORT_VALUE = 'id'.freeze
+
+  ALLOWED_SORT_DIRECTIONS = %w[asc desc].freeze
+  DEFAULT_SORT_DIRECTION = 'asc'.freeze
+
+  def initialize(project, params = {})
+    @project = project
+    @params = params
+  end
+
+  def execute
+    items = init_collection
+    items = by_updated_at(items)
+    sort(items)
+  end
+
+  private
+
+  def init_collection
+    project.deployments
+  end
+
+  # rubocop: disable CodeReuse/ActiveRecord
+  def sort(items)
+    items.order(sort_params)
+  end
+  # rubocop: enable CodeReuse/ActiveRecord
+
+  def by_updated_at(items)
+    items = items.updated_before(params[:updated_before]) if params[:updated_before].present?
+    items = items.updated_after(params[:updated_after]) if params[:updated_after].present?
+
+    items
+  end
+
+  def sort_params
+    order_by = ALLOWED_SORT_VALUES.include?(params[:order_by]) ? params[:order_by] : DEFAULT_SORT_VALUE
+    order_direction = ALLOWED_SORT_DIRECTIONS.include?(params[:sort]) ? params[:sort] : DEFAULT_SORT_DIRECTION
+
+    { order_by => order_direction }
+  end
+end

app/models/deployment.rb

@@ -4,6 +4,7 @@ class Deployment < ApplicationRecord
   include AtomicInternalId
   include IidRoutes
   include AfterCommitQueue
+  include UpdatedAtFilterable
   belongs_to :project, required: true
   belongs_to :environment, required: true

doc/administration/gitaly/praefect.md

@@ -181,7 +181,7 @@ git_data_dirs({
 })
 ```
-For more information on Gitaly server configuration, see our [gitaly documentation](index.md#3-gitaly-server-configuration).
+For more information on Gitaly server configuration, see our [Gitaly documentation](index.md#3-gitaly-server-configuration).
 #### GitLab

doc/administration/gitaly/reference.md

@@ -134,7 +134,7 @@ A lot of Gitaly RPCs need to look up Git objects from repositories.
 Most of the time we use `git cat-file --batch` processes for that. For
 better performance, Gitaly can re-use these `git cat-file` processes
 across RPC calls. Previously used processes are kept around in a
-["git cat-file cache"](https://about.gitlab.com/blog/2019/07/08/git-performance-on-nfs/#enter-cat-file-cache).
+["Git cat-file cache"](https://about.gitlab.com/blog/2019/07/08/git-performance-on-nfs/#enter-cat-file-cache).
 In order to control how much system resources this uses, we have a maximum number
 of cat-file processes that can go into the cache.
@@ -165,11 +165,11 @@ Gitaly restarts its `gitaly-ruby` helpers when their memory exceeds the
 | Name | Type | Required | Description |
 | ---- | ---- | -------- | ----------- |
-| `dir` | string | yes | Path to where gitaly-ruby is installed (needed to boot the process).|
-| `max_rss` | integer | no | Resident set size limit that triggers a gitaly-ruby restart, in bytes. Default is `200000000` (200MB). |
-| `graceful_restart_timeout` | string | no | Grace period before a gitaly-ruby process is forcibly terminated after exceeding `max_rss`. Default is `10m` (10 minutes).|
-| `restart_delay` | string | no |Time that gitaly-ruby memory must remain high before a restart. Default is `5m` (5 minutes).|
-| `num_workers` | integer | no |Number of gitaly-ruby worker processes. Try increasing this number in case of `ResourceExhausted` errors. Default is `2`, minimum is `2`.|
+| `dir` | string | yes | Path to where `gitaly-ruby` is installed (needed to boot the process).|
+| `max_rss` | integer | no | Resident set size limit that triggers a `gitaly-ruby` restart, in bytes. Default is `200000000` (200MB). |
+| `graceful_restart_timeout` | string | no | Grace period before a `gitaly-ruby` process is forcibly terminated after exceeding `max_rss`. Default is `10m` (10 minutes).|
+| `restart_delay` | string | no |Time that `gitaly-ruby` memory must remain high before a restart. Default is `5m` (5 minutes).|
+| `num_workers` | integer | no |Number of `gitaly-ruby` worker processes. Try increasing this number in case of `ResourceExhausted` errors. Default is `2`, minimum is `2`.|
 | `linguist_languages_path` | string | no | Override for dynamic `languages.json` discovery. Defaults to an empty string (use of dynamic discovery).|
 Example:
@@ -231,11 +231,11 @@ The following values configure logging in Gitaly under the `[logging]` section.
 | `level`  | string | no | Log level: `debug`, `info`, `warn`, `error`, `fatal`, or `panic`. Default: `info`. |
 | `sentry_dsn` | string | no | Sentry DSN for exception monitoring. |
 | `sentry_environment` | string | no | [Sentry Environment](https://docs.sentry.io/enriching-error-data/environments/) for exception monitoring. |
-| `ruby_sentry_dsn` | string | no | Sentry DSN for gitaly-ruby exception monitoring. |
+| `ruby_sentry_dsn` | string | no | Sentry DSN for `gitaly-ruby` exception monitoring. |
 While the main Gitaly application logs go to stdout, there are some extra log
 files that go to a configured directory, like the GitLab Shell logs.
-Gitlab Shell does not support `panic` or `trace` level logs. `panic` will fall
+GitLab Shell does not support `panic` or `trace` level logs. `panic` will fall
 back to `error`, while `trace` will fall back to `debug`. Any other invalid log
 levels will default to `info`.

doc/administration/high_availability/README.md

@@ -84,7 +84,7 @@ you can continue with the next step.
 1. [Load Balancer(s)](load_balancer.md)[^2]
 1. [Consul](consul.md)
-1. [PostgreSQL](database.md#postgresql-in-a-scaled-environment) with [PGBouncer](https://docs.gitlab.com/ee/administration/high_availability/pgbouncer.html)
+1. [PostgreSQL](database.md#postgresql-in-a-scaled-environment) with [PgBouncer](https://docs.gitlab.com/ee/administration/high_availability/pgbouncer.html)
 1. [Redis](redis.md#redis-in-a-scaled-environment)
 1. [Gitaly](gitaly.md) (recommended) and / or [NFS](nfs.md)[^4]
 1. [GitLab application nodes](gitlab.md)

doc/administration/index.md

@@ -80,7 +80,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
   - [Backup and restore](../raketasks/backup_restore.md): Backup and restore your GitLab instance.
 - [Operations](operations/index.md): Keeping GitLab up and running (clean up Redis sessions, moving repositories, Sidekiq MemoryKiller, Unicorn).
 - [Restart GitLab](restart_gitlab.md): Learn how to restart GitLab and its components.
-- [Invalidate markdown cache](invalidate_markdown_cache.md): Invalidate any cached markdown.
+- [Invalidate Markdown cache](invalidate_markdown_cache.md): Invalidate any cached Markdown.
 #### Updating GitLab

doc/administration/invalidate_markdown_cache.md

 # Invalidate Markdown Cache
-For performance reasons, GitLab caches the HTML version of markdown text
+For performance reasons, GitLab caches the HTML version of Markdown text
 (e.g. issue and merge request descriptions, comments). It's possible
 that these cached versions become outdated, for example
 when the `external_url` configuration option is changed - causing links

doc/administration/monitoring/prometheus/gitlab_metrics.md

@@ -25,8 +25,8 @@ The following metrics are available:
 | Metric                                                         | Type      |                  Since | Description                                                                                         | Labels                                              |
 |:---------------------------------------------------------------|:----------|-----------------------:|:----------------------------------------------------------------------------------------------------|:----------------------------------------------------|
-| `gitlab_banzai_cached_render_real_duration_seconds`            | Histogram |                    9.4 | Duration of rendering markdown into HTML when cached output exists                                  | controller, action                                  |
-| `gitlab_banzai_cacheless_render_real_duration_seconds`         | Histogram |                    9.4 | Duration of rendering markdown into HTML when cached outupt does not exist                          | controller, action                                  |
+| `gitlab_banzai_cached_render_real_duration_seconds`            | Histogram |                    9.4 | Duration of rendering Markdown into HTML when cached output exists                                  | controller, action                                  |
+| `gitlab_banzai_cacheless_render_real_duration_seconds`         | Histogram |                    9.4 | Duration of rendering Markdown into HTML when cached outupt does not exist                          | controller, action                                  |
 | `gitlab_cache_misses_total`                                    | Counter   |                   10.2 | Cache read miss                                                                                     | controller, action                                  |
 | `gitlab_cache_operation_duration_seconds`                      | Histogram |                   10.2 | Cache access time                                                                                   |                                                     |
 | `gitlab_cache_operations_total`                                | Counter   |                   12.2 | Cache operations by controller/action                                                               | controller, action, operation                       |

doc/administration/raketasks/uploads/migrate.md

@@ -122,10 +122,10 @@ your data out of Object Storage and back into your local storage.
 **Before proceeding, it is important to disable both `direct_upload` and `background_upload` under `uploads` settings in `gitlab.rb`**
 CAUTION: **Warning:**
-   **Extended downtime is required** so no new files are created in object storage during
-   the migration. A configuration setting will be added soon to allow migrating
-   from object storage to local files with only a brief moment of downtime for configuration changes.
-   See issue [gitlab-org/gitlab#30979](https://gitlab.com/gitlab-org/gitlab/issues/30979)
+**Extended downtime is required** so no new files are created in object storage during
+the migration. A configuration setting will be added soon to allow migrating
+from object storage to local files with only a brief moment of downtime for configuration changes.
+To follow progress, see the [relevant issue](https://gitlab.com/gitlab-org/gitlab/issues/30979).
 ### All-in-one rake task

doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md

@@ -923,7 +923,7 @@ queue = Sidekiq::Queue.new('update_merge_requests')
 queue.each { |job| job.delete if job.args[0]==125 and job.args[4]=='ref/heads/my_branch'}
 ```
-**Note:** Running jobs will not be killed. Stop sidekiq before doing this, to get all matching jobs.
+**Note:** Running jobs will not be killed. Stop Sidekiq before doing this, to get all matching jobs.
 ### Enable debug logging of Sidekiq

doc/administration/troubleshooting/postgresql.md

@@ -46,7 +46,7 @@ This section is for links to information elsewhere in the GitLab documentation.
 - Managing Omnibus PostgreSQL versions [from the development docs](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions.html)
 - [PostgreSQL scaling and HA](../high_availability/database.md)
-  - including [troubleshooting](../high_availability/database.md#troubleshooting) gitlab-ctl repmgr-check-master and pgbouncer errors
+  - including [troubleshooting](../high_availability/database.md#troubleshooting) `gitlab-ctl repmgr-check-master` and PgBouncer errors
 - [Developer database documentation](../../development/README.md#database-guides) - some of which is absolutely not for production use. Including:
   - understanding EXPLAIN plans
@@ -58,7 +58,7 @@ This section is for links to information elsewhere in the GitLab documentation.
   - required extension pg_trgm
   - required extension postgres_fdw for Geo
-- Errors like this in the production/sidekiq log;  see: [Set default_transaction_isolation into read committed](https://docs.gitlab.com/omnibus/settings/database.html#set-default_transaction_isolation-into-read-committed)
+- Errors like this in the `production / Sidekiq` log; see: [Set default_transaction_isolation into read committed](https://docs.gitlab.com/omnibus/settings/database.html#set-default_transaction_isolation-into-read-committed)
 ```
 ActiveRecord::StatementInvalid PG::TRSerializationFailure: ERROR:  could not serialize access due to concurrent update
@@ -96,7 +96,7 @@ PANIC: could not write to file ‘pg_xlog/xlogtemp.123’: No space left on devi
 References:
 - [Issue #1 Deadlocks with GitLab 12.1, PostgreSQL 10.7](https://gitlab.com/gitlab-org/gitlab/issues/30528)
-- [Customer ticket (internal) GitLab 12.1.6](https://gitlab.zendesk.com/agent/tickets/134307) and [google doc (internal)](https://docs.google.com/document/d/19xw2d_D1ChLiU-MO1QzWab-4-QXgsIUcN5e_04WTKy4)
+- [Customer ticket (internal) GitLab 12.1.6](https://gitlab.zendesk.com/agent/tickets/134307) and [Google doc (internal)](https://docs.google.com/document/d/19xw2d_D1ChLiU-MO1QzWab-4-QXgsIUcN5e_04WTKy4)
 - [Issue #2 deadlocks can occur if an instance is flooded with pushes](https://gitlab.com/gitlab-org/gitlab/issues/33650). Provided for context about how GitLab code can have this sort of unanticipated effect in unusual situations.
 ```
@@ -117,7 +117,7 @@ Quoting from from issue [#1](https://gitlab.com/gitlab-org/gitlab/issues/30528):
 TIP: **Tip:** In support, our general approach to reconfiguring timeouts (applies also to the HTTP stack as well) is that it's acceptable to do it temporarily as a workaround. If it makes GitLab usable for the customer, then it buys time to understand the problem more completely, implement a hot fix, or make some other change that addresses the root cause. Generally, the timeouts should be put back to reasonable defaults once the root cause is resolved.
-In this case, the guidance we had from development was to drop deadlock_timeout and/or statement_timeout but to leave the third setting at 60s. Setting idle_in_transaction protects the database from sessions potentially hanging for days. There's more discussion in [the issue relating to introducing this timeout on gitlab.com.](https://gitlab.com/gitlab-com/gl-infra/production/issues/1053)
+In this case, the guidance we had from development was to drop deadlock_timeout and/or statement_timeout but to leave the third setting at 60s. Setting idle_in_transaction protects the database from sessions potentially hanging for days. There's more discussion in [the issue relating to introducing this timeout on GitLab.com](https://gitlab.com/gitlab-com/gl-infra/production/issues/1053).
 PostgresSQL defaults:

doc/api/deployments.md

@@ -13,6 +13,8 @@ GET /projects/:id/deployments
 | `id`      | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
 | `order_by`| string  | no       | Return deployments ordered by `id` or `iid` or `created_at` or `updated_at` or `ref` fields. Default is `id` |
 | `sort`    | string  | no       | Return deployments sorted in `asc` or `desc` order. Default is `asc` |
+| `updated_after` | datetime | no | Return deployments updated after the specified date |
+| `updated_before` | datetime | no | Return deployments updated before the specified date |
 ```bash
 curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/deployments"

doc/api/markdown.md

@@ -12,7 +12,7 @@ POST /api/v4/markdown
 | Attribute | Type    | Required      | Description                                |
 | --------- | ------- | ------------- | ------------------------------------------ |
-| `text`    | string  | yes           | The markdown text to render                |
+| `text`    | string  | yes           | The Markdown text to render                |
 | `gfm`     | boolean | no (optional) | Render text using GitLab Flavored Markdown. Default is `false` |
 | `project` | string  | no (optional) | Use `project` as a context when creating references using GitLab Flavored Markdown. [Authentication](README.html#authentication) is required if a project is not public.  |

doc/api/releases/index.md

@@ -312,7 +312,7 @@ POST /projects/:id/releases
 | `id`               | integer/string  | yes                         | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding).                                              |
 | `name`             | string          | no                          | The release name.                                                                                                                |
 | `tag_name`         | string          | yes                         | The tag where the release will be created from.                                                                                  |
-| `description`      | string          | yes                         | The description of the release. You can use [markdown](../../user/markdown.md).                                                  |
+| `description`      | string          | yes                         | The description of the release. You can use [Markdown](../../user/markdown.md).                                                  |
 | `ref`              | string          | yes, if `tag_name` doesn't exist | If `tag_name` doesn't exist, the release will be created from `ref`. It can be a commit SHA, another tag name, or a branch name. |
 | `milestones`       | array of string | no                          | The title of each milestone the release is associated with.                                                                      |
 | `assets:links`     | array of hash   | no                          | An array of assets links.                                                                                                        |
@@ -439,7 +439,7 @@ PUT /projects/:id/releases/:tag_name
 | `id`          | integer/string  | yes      | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding).                         |
 | `tag_name`    | string          | yes      | The tag where the release will be created from.                                                             |
 | `name`        | string          | no       | The release name.                                                                                           |
-| `description` | string          | no       | The description of the release. You can use [markdown](../../user/markdown.md).                             |
+| `description` | string          | no       | The description of the release. You can use [Markdown](../../user/markdown.md).                             |
 | `milestones`  | array of string | no       | The title of each milestone to associate with the release (`[]` to remove all milestones from the release). |
 | `released_at` | datetime        | no       | The date when the release will be/was ready. Expected in ISO 8601 format (`2019-03-15T08:00:00Z`).          |

doc/api/settings.md

@@ -265,7 +265,7 @@ are listed in the descriptions of the relevant settings.
 | `html_emails_enabled`                    | boolean          | no                                   | Enable HTML emails. |
 | `import_sources`                         | array of strings | no                                   | Sources to allow project import from, possible values: `github`, `bitbucket`, `bitbucket_server`, `gitlab`, `google_code`, `fogbugz`, `git`, `gitlab_project`, `gitea`, `manifest`, and `phabricator`. |
 | `instance_statistics_visibility_private` | boolean          | no                                   | When set to `true` Instance statistics will only be available to admins. |
-| `local_markdown_version`                 | integer          | no                                   | Increase this value when any cached markdown should be invalidated. |
+| `local_markdown_version`                 | integer          | no                                   | Increase this value when any cached Markdown should be invalidated. |
 | `max_artifacts_size`                     | integer          | no                                   | Maximum artifacts size in MB |
 | `max_attachment_size`                    | integer          | no                                   | Limit attachment size in MB |
 | `max_pages_size`                         | integer          | no                                   | Maximum size of pages repositories in MB |

doc/api/tags.md

@@ -189,7 +189,7 @@ Parameters:
 Request body:
-- `description` (required) - Release notes with markdown support
+- `description` (required) - Release notes with Markdown support
 ```json
 {
@@ -221,7 +221,7 @@ Parameters:
 Request body:
-- `description` (required) - Release notes with markdown support
+- `description` (required) - Release notes with Markdown support
 ```json
 {

doc/user/admin_area/appearance.md

@@ -46,8 +46,8 @@ of your GitLab instance. These messages will appear on all projects and pages of
 instance, including the sign in / sign up page. The default color is white text on
 an orange background, but this can be customized by clicking on **Customize colors**.
-Limited [markdown](../markdown.md) is supported, such as bold, italics, and links, for
-example. Other markdown features, including lists, images and quotes, are not supported,
+Limited [Markdown](../markdown.md) is supported, such as bold, italics, and links, for
+example. Other Markdown features, including lists, images and quotes, are not supported,
 as the header and footer messages can only be a single line.
 ![header and footer screenshot](img/appearance_header_footer_v12_3.png)
@@ -61,7 +61,7 @@ to activate it in the GitLab instance.
 ## Sign in / Sign up pages
 You can replace the default message on the sign in / sign up page with your own message
-and logo. You can make full use of [markdown](../markdown.md) in the description:
+and logo. You can make full use of [Markdown](../markdown.md) in the description:
 ![sign in message screenshot](img/appearance_sign_in_v12_3.png)
@@ -81,7 +81,7 @@ You can add also add a [customized help message](settings/help_page.md) below th
 ## New project pages
 You can add a new project guidelines message to the **New project page** within GitLab.
-You can make full use of [markdown](../markdown.md) in the description:
+You can make full use of [Markdown](../markdown.md) in the description:
 ![new project message screenshot](img/appearance_new_project_v12_3.png)

doc/user/admin_area/monitoring/health_check.md

@@ -103,7 +103,7 @@ This check is being exempt from Rack Attack.
 ## Liveness
 DANGER: **Warning:**
-In Gitlab [12.4](https://about.gitlab.com/upcoming-releases/)
+In GitLab [12.4](https://about.gitlab.com/upcoming-releases/)
 the response body of the Liveness check was changed
 to match the example below.

doc/user/application_security/container_scanning/index.md

@@ -127,7 +127,7 @@ If you want to whitelist specific vulnerabilities, you'll need to:
    [overriding the Container Scanning template](#overriding-the-container-scanning-template) section of this document.
    1. Define the whitelisted vulnerabilities in a YAML file named `clair-whitelist.yml` which must use the format described
    in the [following whitelist example file](https://github.com/arminc/clair-scanner/blob/v12/example-whitelist.yaml).
-   1. Add the `clair-whitelist.yml` file to the git repository of your project
+   1. Add the `clair-whitelist.yml` file to the Git repository of your project
 ### Overriding the Container Scanning template

doc/user/application_security/dast/index.md

@@ -85,7 +85,7 @@ There are two ways to define the URL to be scanned by DAST:
 1. Add it in an `environment_url.txt` file at the root of your project.
     This is great for testing in dynamic environments. In order to run DAST against
-    an app that is dynamically created during a Gitlab CI pipeline, have the app
+    an app that is dynamically created during a GitLab CI pipeline, have the app
     persist its domain in an `environment_url.txt` file, and DAST will
     automatically parse that file to find its scan target.
     You can see an [example](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml)
@@ -228,7 +228,7 @@ server {
 ###### Apache
 Apache can also be used as a [reverse proxy](https://httpd.apache.org/docs/2.4/mod/mod_proxy.html)
-to add the Gitlab-DAST-Permission [header](https://httpd.apache.org/docs/current/mod/mod_headers.html).
+to add the `Gitlab-DAST-Permission` [header](https://httpd.apache.org/docs/current/mod/mod_headers.html).
 To do so, add the following lines to `httpd.conf`: