Add latest changes from gitlab-org/gitlab@master

doc/development/api_graphql_styleguide.md

@@ -547,7 +547,7 @@ argument :project_path, GraphQL::ID_TYPE,
          required: true,
          description: "The project the merge request to mutate is in"
-argument :iid, GraphQL::ID_TYPE,
+argument :iid, GraphQL::STRING_TYPE,
          required: true,
          description: "The iid of the merge request to mutate"

doc/development/contributing/issue_workflow.md

@@ -40,7 +40,7 @@ scheduling into milestones. Labelling is a task for everyone.
 Most issues will have labels for at least one of the following:
-- Type: `~feature`, `~bug`, `~backstage`, etc.
+- Type: `~feature`, `~bug`, `~backstage`, `~documentation`, etc.
 - Stage: `~"devops::plan"`, `~"devops::create"`, etc.
 - Group: `~"group::source code"`, `~"group::knowledge"`, `~"group::editor"`, etc.
 - Category: `~"Category:Code Analytics"`, `~"Category:DevOps Score"`, `~"Category:Templates"`, etc.
@@ -70,6 +70,7 @@ The current type labels are:
 - ~backstage
 - ~"support request"
 - ~meta
+- ~documentation
 A number of type labels have a priority assigned to them, which automatically
 makes them float to the top, depending on their importance.

doc/development/documentation/workflow.md

@@ -20,8 +20,7 @@ directly affect the way that any user or administrator interacts with GitLab.
 Regardless of the type of issue or merge request, certain labels are required when documentation
 is added or updated. The following are added by the issue or merge request author:
-- An appropriate [type label](../contributing/issue_workflow.md#type-labels). For example,
-  `~backstage`.
+- An appropriate [type label](../contributing/issue_workflow.md#type-labels).
 - The [stage label](../contributing/issue_workflow.md#stage-labels) and
   [group label](../contributing/issue_workflow.md#group-labels). For example, `~devops::create` and
   `~group::source code`.
@@ -377,8 +376,10 @@ For complex features split over multiple merge requests:
 ## For all other documentation
-These documentation changes are not associated with the release of a new or updated feature, and are
-therefore labeled `backstage` in GitLab, rather than `feature`. They may include:
+Documentation changes that are not associated with the release of a new or updated feature
+do not take the `~feature` label, but still need the `~documentation` label.
+
+They may include:
 - Documentation created or updated to improve accuracy, completeness, ease of use, or any reason
   other than a [feature change](#for-a-product-change).

doc/install/requirements.md

@@ -186,6 +186,23 @@ As long as you have enough available CPU and memory capacity, it's okay to incre
 To change the Unicorn workers when you have the Omnibus package (which defaults to the recommendation above) please see [the Unicorn settings in the Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/unicorn.html).
+## Puma Workers
+
+For most instances we recommend using: max(CPU cores * 0.9, 2) = Puma workers.
+For example a node with 4 cores would have 3 Unicorn workers.
+
+For all machines that have 4GB and up we recommend a minimum of three Puma workers.
+If you have a 2GB machine we recommend to configure only one Puma worker to prevent excessive swapping.
+
+By default each Puma worker runs with 4 threads. We do not recommend setting more,
+due to how [Ruby MRI multi-threading](https://en.wikipedia.org/wiki/Global_interpreter_lock) works.
+
+For cases when you have to use [Legacy Rugged code](../development/gitaly.md#legacy-rugged-code) it is recommended to set number of threads to 1.
+
+As long as you have enough available CPU and memory capacity, it's okay to increase the number of Puma workers and this will usually help to reduce the response time of the applications and increase the ability to handle parallel requests.
+
+To change the Puma workers when you have the Omnibus package (which defaults to the recommendation above) please see [the Puma settings in the Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/puma.html).
+
 ## Redis and Sidekiq
 Redis stores all user sessions and the background task queue.

doc/user/analytics/value_stream_analytics.md

@@ -25,12 +25,7 @@ calculates a separate median for each stage.
 Value Stream Analytics is available:
-- From GitLab 12.3, at the group level in the analytics workspace (top navigation bar) at
-  **Analytics > Value Stream Analytics**. **(PREMIUM)**
-
-  In the future, multiple groups will be selectable which will effectively make this an
-  instance-level feature.
-
+- From GitLab 12.9, at the group level via **Group > Analytics > Value Stream**. **(PREMIUM)**
 - At the project level via **Project > Value Stream Analytics**.
 There are seven stages that are tracked as part of the Value Stream Analytics calculations.

doc/user/project/releases/index.md

@@ -67,7 +67,43 @@ links from your GitLab instance.
 NOTE: **NOTE**
 You can manipulate links of each release entry with [Release Links API](../../../api/releases/links.md)
-#### Releases associated with milestones
+#### Permanent links to Release assets
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/27300) in GitLab 12.9.
+
+The assets associated with a Release are accessible through a permanent URL.
+GitLab will always redirect this URL to the actual asset
+location, so even if the assets move to a different location, you can continue
+to use the same URL. This is defined during [link creation](../../../api/releases/links.md#create-a-link) or [updating](../../../api/releases/links.md#update-a-link).
+
+Each asset has a name, a URL of the *actual* asset location, and optionally, a
+`filepath` parameter, which, if you specify it, will create a URL pointing
+to the asset for the Release. The format of the URL is:
+
+```html
+https://host/namespace/project/releases/:release/downloads/:filepath
+```
+
+If you have an asset for the `v11.9.0-rc2` release in the `gitlab-org`
+namespace and `gitlab-runner` project on `gitlab.com`, for example:
+
+```json
+{
+  "name": "linux amd64",
+  "filepath": "/binaries/gitlab-runner-linux-amd64",
+  "url": "https://gitlab-runner-downloads.s3.amazonaws.com/v11.9.0-rc2/binaries/gitlab-runner-linux-amd64"
+}
+```
+
+This asset has a direct link of:
+
+```html
+https://gitlab.com/gitlab-org/gitlab-runner/releases/v11.9.0-rc2/downloads/binaries/gitlab-runner-linux-amd64
+```
+
+The physical location of the asset can change at any time and the direct link will remain unchanged.
+
+### Releases associated with milestones
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/29020) in GitLab 12.5.

lib/gitlab/ci/config/external/file/artifact.rb

@@ -30,7 +30,7 @@ module Gitlab
             def matching?
               super &&
-                Feature.enabled?(:ci_dynamic_child_pipeline, project)
+                Feature.enabled?(:ci_dynamic_child_pipeline, project, default_enabled: true)
             end
             private

locale/gitlab.pot

@@ -13858,6 +13858,9 @@ msgstr ""
 msgid "PackageRegistry|Add NuGet Source"
 msgstr ""
+msgid "PackageRegistry|Conan"
+msgstr ""
+
 msgid "PackageRegistry|Conan Command"
 msgstr ""
@@ -13921,12 +13924,21 @@ msgstr ""
 msgid "PackageRegistry|Learn how to %{noPackagesLinkStart}publish and share your packages%{noPackagesLinkEnd} with GitLab."
 msgstr ""
+msgid "PackageRegistry|Maven"
+msgstr ""
+
 msgid "PackageRegistry|Maven Command"
 msgstr ""
 msgid "PackageRegistry|Maven XML"
 msgstr ""
+msgid "PackageRegistry|NPM"
+msgstr ""
+
+msgid "PackageRegistry|NuGet"
+msgstr ""
+
 msgid "PackageRegistry|NuGet Command"
 msgstr ""
@@ -13942,6 +13954,9 @@ msgstr ""
 msgid "PackageRegistry|Remove package"
 msgstr ""
+msgid "PackageRegistry|There are no %{packageType} packages yet"
+msgstr ""
+
 msgid "PackageRegistry|There are no packages yet"
 msgstr ""

spec/lib/gitlab/diff/highlight_cache_spec.rb

@@ -53,26 +53,22 @@ describe Gitlab::Diff::HighlightCache, :clean_gitlab_redis_cache do
                              fallback_diff_refs: diffs.fallback_diff_refs)
     end
-    it 'does not calculate highlighting when reading from cache' do
+    before do
       cache.write_if_empty
       cache.decorate(diff_file)
+    end
+    it 'does not calculate highlighting when reading from cache' do
       expect_any_instance_of(Gitlab::Diff::Highlight).not_to receive(:highlight)
       diff_file.highlighted_diff_lines
     end
     it 'assigns highlighted diff lines to the DiffFile' do
-      cache.write_if_empty
-      cache.decorate(diff_file)
-
       expect(diff_file.highlighted_diff_lines.size).to be > 5
     end
     it 'assigns highlighted diff lines which rich_text are HTML-safe' do
-      cache.write_if_empty
-      cache.decorate(diff_file)
-
       rich_texts = diff_file.highlighted_diff_lines.map(&:rich_text)
       expect(rich_texts).to all(be_html_safe)