Add latest changes from gitlab-org/gitlab@12-5-stable-ee

doc/ci/yaml/README.md

@@ -1539,9 +1539,14 @@ cache:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/18986) in GitLab v12.5.
-If `cache:key:files` is added, one or two files must be defined with it. The cache `key`
-will be a SHA computed from the most recent commits (one or two) that changed the
-given files. If neither file was changed in any commits, the key will be `default`.
+The `cache:key:files` keyword extends the `cache:key` functionality by making it easier
+to reuse some caches, and rebuild them less often, which will speed up subsequent pipeline
+runs.
+
+When you include `cache:key:files`, you must also list the project files that will be used to generate the key, up to a maximum of two files.
+The cache `key` will be a SHA checksum computed from the most recent commits (up to two, if two files are listed)
+that changed the given files. If neither file was changed in any commits,
+the fallback key will be `default`.
 ```yaml
 cache:
@@ -1554,20 +1559,26 @@ cache:
     - node_modules
 ```
+In this example we are creating a cache for Ruby and Nodejs dependencies that
+is tied to current versions of the `Gemfile.lock` and `package.json` files. Whenever one of
+these files changes, a new cache key is computed and a new cache is created. Any future
+job runs using the same `Gemfile.lock` and `package.json`  with `cache:key:files` will
+use the new cache, instead of rebuilding the dependencies.
+
 ##### `cache:key:prefix`
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/18986) in GitLab v12.5.
-
 The `prefix` parameter adds extra functionality to `key:files` by allowing the key to
 be composed of the given `prefix` combined with the SHA computed for `cache:key:files`.
-For example, adding a `prefix` of `rspec`, will
-cause keys to look like: `rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5`. If neither
-file was changed in any commits, the prefix is added to `default`, so the key in the
-example would be `rspec-default`.
-`prefix` follows the same restrictions as `key`, so it can use any of the
-[predefined variables](../variables/README.md). Similarly, the `/` character or the
-equivalent URI-encoded `%2F`, or a value made only of `.` or `%2E`, is not allowed.
+For example, adding a `prefix` of `test`, will cause keys to look like: `test-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5`.
+If neither file was changed in any commits, the prefix is added to `default`, so the
+key in the example would be `test-default`.
+Like `cache:key`, `prefix` can use any of the [predefined variables](../variables/README.md),
+but the following are not allowed:
+
+- the `/` character (or the equivalent URI-encoded `%2F`)
+- a value made only of `.` (or the equivalent URI-encoded `%2E`)
 ```yaml
 cache:
@@ -1577,8 +1588,20 @@ cache:
     prefix: ${CI_JOB_NAME}
   paths:
     - vendor/ruby
+
+rspec:
+  script:
+    - bundle exec rspec
 ```
+For example, adding a `prefix` of `$CI_JOB_NAME` will
+cause the key to look like: `rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5` and
+the job cache is shared across different branches. If a branch changes
+`Gemfile.lock`, that branch will have a new SHA checksum for `cache:key:files`. A new cache key
+will be generated, and a new cache will be created for that key.
+If `Gemfile.lock` is not found, the prefix is added to
+`default`, so the key in the example would be `rspec-default`.
+
 #### `cache:untracked`
 Set `untracked: true` to cache all files that are untracked in your Git

doc/integration/sourcegraph.md

@@ -108,9 +108,10 @@ When visiting one of these views, you can now hover over a code reference to see
 Sourcegraph powered code intelligence will be incrementally rolled out on GitLab.com.
 It will eventually become available for all public projects, but for now, it is only
-available for some specific [`gitlab-org` projects](https://gitlab.com/gitlab-org/).
-This means that you can see it working and use it to dig into the code of these projects,
-but you cannot use it on your own project on GitLab.com yet.
+available for some specific projects within the [`gitlab-org`](https://gitlab.com/gitlab-org/)
+group, e.g., <https://gitlab.com/gitlab-org/gitlab>. This means that you can see
+it working and use it to dig into the code of these projects, but you cannot use
+it on your own project on GitLab.com yet.
 If you would like to use it in your own projects as of GitLab 12.5, you can do so by
 setting up a self-managed GitLab instance.

doc/user/admin_area/settings/continuous_integration.md

@@ -161,6 +161,11 @@ but commented out to help encourage others to add to it in the future. -->
 ## Required pipeline configuration **(PREMIUM ONLY)**
+CAUTION: **Caution:**
+The Required Pipeline Configuration feature is deprecated and will be removed when an
+[improved compliance solution](https://gitlab.com/gitlab-org/gitlab/issues/34830)
+is added to GitLab. It is recommended to avoid using this feature.
+
 GitLab administrators can force a pipeline configuration to run on every
 pipeline.

doc/user/application_security/sast/analyzers.md

@@ -15,7 +15,7 @@ SAST supports the following official analyzers:
 - [`bandit`](https://gitlab.com/gitlab-org/security-products/analyzers/bandit) (Bandit)
 - [`brakeman`](https://gitlab.com/gitlab-org/security-products/analyzers/brakeman) (Brakeman)
-- [`eslint`](https://gitlab.com/gitlab-org/security-products/analyzers/eslint) (ESLint (JavaScript))
+- [`eslint`](https://gitlab.com/gitlab-org/security-products/analyzers/eslint) (ESLint (JavaScript and React))
 - [`flawfinder`](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder) (Flawfinder)
 - [`gosec`](https://gitlab.com/gitlab-org/security-products/analyzers/gosec) (Gosec)
 - [`nodejs-scan`](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan) (NodeJsScan)

doc/user/application_security/sast/index.md

@@ -76,6 +76,7 @@ The following table shows which languages, package managers and frameworks are s
 | Node.js                                                                     | [NodeJsScan](https://github.com/ajinabraham/NodeJsScan)                                | 11.1                         |
 | PHP                                                                         | [phpcs-security-audit](https://github.com/FloeDesignTechnologies/phpcs-security-audit) | 10.8                         |
 | Python ([pip](https://pip.pypa.io/en/stable/))                              | [bandit](https://github.com/PyCQA/bandit)                                              | 10.3                         |
+| React                                                                       | [ESLint react plugin](https://github.com/yannickcr/eslint-plugin-react)                | 12.5                         |
 | Ruby on Rails                                                               | [brakeman](https://brakemanscanner.org)                                                | 10.3                         |
 | Scala ([Ant](https://ant.apache.org/), [Gradle](https://gradle.org/), [Maven](https://maven.apache.org/) and [SBT](https://www.scala-sbt.org/)) | [SpotBugs](https://spotbugs.github.io/) with the [find-sec-bugs](https://find-sec-bugs.github.io/) plugin | 11.0 (SBT) & 11.9 (Ant, Gradle, Maven) |
 | TypeScript                                                                  | [TSLint config security](https://github.com/webschik/tslint-config-security/)          | 11.9                         |

doc/user/application_security/security_dashboard/index.md

@@ -71,7 +71,7 @@ Once you're on the dashboard, at the top you should see a series of filters for:
 - Report type
 - Project
-To the right of the filters, you should see a **Hide dismissed** toggle button ([available in GitLab Ultimate 12.5](https://gitlab.com/gitlab-org/gitlab/issues/9102)).
+To the right of the filters, you should see a **Hide dismissed** toggle button ([available for GitLab.com Gold, planned for GitLab Ultimate 12.6](https://gitlab.com/gitlab-org/gitlab/issues/9102)).
 NOTE: **Note:**
 The dashboard only shows projects with [security reports](#supported-reports) enabled in a group.

doc/user/clusters/applications.md

@@ -417,6 +417,18 @@ install Crossplane using the
 [`values.yaml`](https://github.com/crossplaneio/crossplane/blob/master/cluster/charts/crossplane/values.yaml.tmpl)
 file.
+#### Enabling installation
+
+This is a preliminary release of Crossplane as a GitLab-managed application. By default,
+the ability to install it is disabled.
+
+To allow installation of Crossplane as a GitLab-managed application, ask a GitLab
+administrator to run following command within a Rails console:
+
+```ruby
+Feature.enable(:enable_cluster_application_crossplane)
+```
+
 ## Upgrading applications
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/24789) in GitLab 11.8.

doc/user/group/epics/index.md

@@ -50,14 +50,17 @@ Any issue that belongs to a project in the epic's group, or any of the epic's
 subgroups, are eligible to be added.  New issues appear at the top of the list of issues in the **Epics and Issues** tab.
 An epic contains a list of issues and an issue can be associated with at most
-one epic. When you add an issue to an epic that is already associated with another epic,
-the issue is automatically removed from the previous epic.
+one epic. When you add an issue that is already linked to an epic,
+the issue is automatically unlinked from its current parent.
 To add an issue to an epic:
 1. Click **Add an issue**.
-1. Paste the link of the issue.
-   - Press <kbd>Spacebar</kbd> and repeat this step if there are multiple issues.
+1. Identify the issue to be added, using either of the following methods:
+   - Paste the link of the issue.
+   - Search for the desired issue by entering part of the issue's title, then selecting the desired match. ([From GitLab 12.5](https://gitlab.com/gitlab-org/gitlab/issues/9126))
+
+   If there are multiple issues to be added, press <kbd>Spacebar</kbd> and repeat this step.
 1. Click **Add**.
 To remove an issue from an epic:
@@ -72,17 +75,19 @@ To remove an issue from an epic:
 Any epic that belongs to a group, or subgroup of the parent epic's group, is
 eligible to be added. New child epics appear at the top of the list of epics in the **Epics and Issues** tab.
-When you add a child epic that is already associated with another epic,
-that epic is automatically removed from the previous epic.
+When you add an epic that is already linked to a parent epic, the link to its current parent is removed.
 An epic can have multiple child epics with
 the maximum depth being 5.
-To add a child epic:
+To add a child epic to an epic:
 1. Click **Add an epic**.
-1. Paste the link of the epic.
-   - Press <kbd>Spacebar</kbd> and repeat this step if there are multiple issues.
+1. Identify the epic to be added, using either of the following methods:
+   - Paste the link of the epic.
+   - Search for the desired issue by entering part of the epic's title, then selecting the desired match. ([From GitLab 12.5](https://gitlab.com/gitlab-org/gitlab/issues/9126))
+
+   If there are multiple epics to be added, press <kbd>Spacebar</kbd> and repeat this step.
 1. Click **Add**.
 To remove a child epic from a parent epic:

doc/user/operations_dashboard/index.md

@@ -23,6 +23,8 @@ To add a project to the dashboard:
 Once added, the dashboard will display the project's number of active alerts,
 last commit, pipeline status, and when it was last deployed.
+The Operations and [Environments](../../ci/environments/environments_dashboard.md) dashboards share the same list of projects. Adding or removing a project from one adds or removes the project from the other.
+
 ![Operations Dashboard with projects](img/index_operations_dashboard_with_projects.png)
 ## Arranging projects on a dashboard

doc/user/project/clusters/add_remove_clusters.md

@@ -206,9 +206,46 @@ GitLab supports:
 Before creating your first cluster on Amazon EKS with GitLab's integration,
 make sure the following requirements are met:
+- Enable the `create_eks_clusters` feature flag for your GitLab instance.
 - An [Amazon Web Services](https://aws.amazon.com/) account is set up and you are able to log in.
 - You have permissions to manage IAM resources.
+#### Enable the `create_eks_clusters` feature flag **(CORE ONLY)**
+
+NOTE: **Note:**
+If you are running a self-managed instance, EKS cluster creation will not be available
+unless the feature flag `create_eks_clusters` is enabled. This can be done from the Rails console
+by instance administrators.
+
+Use these commands to start the Rails console:
+
+```sh
+# Omnibus GitLab
+gitlab-rails console
+
+# Installation from source
+cd /home/git/gitlab
+sudo -u git -H bin/rails console RAILS_ENV=production
+```
+
+Then run the following command to enable the feature flag:
+
+```
+Feature.enable(:create_eks_clusters)
+```
+
+You can also enable the feature flag only for specific projects with:
+
+```
+Feature.enable(:create_eks_clusters, Project.find_by_full_path('my_group/my_project'))
+```
+
+Run the following command to disable the feature flag:
+
+```
+Feature.disable(:create_eks_clusters)
+```
+
 ##### Additional requirements for self-managed instances
 If you are using a self-managed GitLab instance, GitLab must first
@@ -262,55 +299,55 @@ new Kubernetes cluster to your project:
    1. Click **Create Policy**, which will open a new window.
    1. Select the **JSON** tab, and paste in the following snippet in place of the existing content:
-    ```json
-    {
-        "Version": "2012-10-17",
-        "Statement": [
-            {
-                "Effect": "Allow",
-                "Action": [
-                    "autoscaling:CreateAutoScalingGroup",
-                    "autoscaling:DescribeAutoScalingGroups",
-                    "autoscaling:DescribeScalingActivities",
-                    "autoscaling:UpdateAutoScalingGroup",
-                    "autoscaling:CreateLaunchConfiguration",
-                    "autoscaling:DescribeLaunchConfigurations",
-                    "cloudformation:CreateStack",
-                    "cloudformation:DescribeStacks",
-                    "ec2:AuthorizeSecurityGroupEgress",
-                    "ec2:AuthorizeSecurityGroupIngress",
-                    "ec2:RevokeSecurityGroupEgress",
-                    "ec2:RevokeSecurityGroupIngress",
-                    "ec2:CreateSecurityGroup",
-                    "ec2:createTags",
-                    "ec2:DescribeImages",
-                    "ec2:DescribeKeyPairs",
-                    "ec2:DescribeRegions",
-                    "ec2:DescribeSecurityGroups",
-                    "ec2:DescribeSubnets",
-                    "ec2:DescribeVpcs",
-                    "eks:CreateCluster",
-                    "eks:DescribeCluster",
-                    "iam:AddRoleToInstanceProfile",
-                    "iam:AttachRolePolicy",
-                    "iam:CreateRole",
-                    "iam:CreateInstanceProfile",
-                    "iam:GetRole",
-                    "iam:ListRoles",
-                    "iam:PassRole",
-                    "ssm:GetParameters"
-                ],
-                "Resource": "*"
-            }
-        ]
-    }
-    ```
-
-    NOTE: **Note:**
-    These permissions give GitLab the ability to create resources, but not delete them.
-    This means that if an error is encountered during the creation process, changes will
-    not be rolled back and you must remove resources manually. You can do this by deleting
-    the relevant [CloudFormation stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)
+      ```json
+      {
+          "Version": "2012-10-17",
+          "Statement": [
+              {
+                  "Effect": "Allow",
+                  "Action": [
+                      "autoscaling:CreateAutoScalingGroup",
+                      "autoscaling:DescribeAutoScalingGroups",
+                      "autoscaling:DescribeScalingActivities",
+                      "autoscaling:UpdateAutoScalingGroup",
+                      "autoscaling:CreateLaunchConfiguration",
+                      "autoscaling:DescribeLaunchConfigurations",
+                      "cloudformation:CreateStack",
+                      "cloudformation:DescribeStacks",
+                      "ec2:AuthorizeSecurityGroupEgress",
+                      "ec2:AuthorizeSecurityGroupIngress",
+                      "ec2:RevokeSecurityGroupEgress",
+                      "ec2:RevokeSecurityGroupIngress",
+                      "ec2:CreateSecurityGroup",
+                      "ec2:createTags",
+                      "ec2:DescribeImages",
+                      "ec2:DescribeKeyPairs",
+                      "ec2:DescribeRegions",
+                      "ec2:DescribeSecurityGroups",
+                      "ec2:DescribeSubnets",
+                      "ec2:DescribeVpcs",
+                      "eks:CreateCluster",
+                      "eks:DescribeCluster",
+                      "iam:AddRoleToInstanceProfile",
+                      "iam:AttachRolePolicy",
+                      "iam:CreateRole",
+                      "iam:CreateInstanceProfile",
+                      "iam:GetRole",
+                      "iam:ListRoles",
+                      "iam:PassRole",
+                      "ssm:GetParameters"
+                  ],
+                  "Resource": "*"
+              }
+          ]
+      }
+      ```
+
+      NOTE: **Note:**
+      These permissions give GitLab the ability to create resources, but not delete them.
+      This means that if an error is encountered during the creation process, changes will
+      not be rolled back and you must remove resources manually. You can do this by deleting
+      the relevant [CloudFormation stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)
    1. Click **Review policy**.
    1. Enter a suitable name for this policy, and click **Create Policy**. You can now close this window.

doc/user/project/issues/issue_data_and_actions.md

@@ -157,6 +157,8 @@ The plain text title and description of the issue fill the top center of the iss
 The description fully supports [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm),
 allowing many formatting options.
+> [Since GitLab 12.5](https://gitlab.com/gitlab-org/gitlab/issues/10103), changes to an issue's description are listed in the [issue history](#23-issue-history).**(STARTER)**
+
 #### 17. Mentions
 You can mention a user or a group present in your GitLab instance with `@username` or

doc/user/project/releases/index.md

@@ -147,7 +147,7 @@ You can also edit an existing tag to add release notes:
 ## Release Evidence
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/26019) in GitLab 12.5.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/26019) in GitLab 12.6.
 Each time a new release is created, specific related data is collected in
 parallel. This dataset will be a snapshot this new release (including linked
@@ -155,7 +155,7 @@ milestones and issues) at moment of creation. Such collection of data will
 provide a chain of custody and facilitate processes like external audits, for example.
 The gathered Evidence data is stored in the database upon creation of a new
-release as a JSON object. In GitLab 12.5, a link to
+release as a JSON object. In GitLab 12.6, a link to
 the Evidence data is provided for [each Release](#releases-list).
 Here's what this object can look like:

lib/api/projects.rb

@@ -191,6 +191,7 @@ module API
         optional :path, type: String, desc: 'The path of the repository'
         optional :default_branch, type: String, desc: 'The default branch of the project'
         use :optional_project_params
+        use :optional_create_project_params
         use :create_params
       end
       # rubocop: disable CodeReuse/ActiveRecord

lib/gitlab/exception_log_formatter.rb

+# frozen_string_literal: true
+
+module Gitlab
+  module ExceptionLogFormatter
+    def self.format!(exception, payload)
+      return unless exception
+
+      # Elasticsearch/Fluentd don't handle nested structures well.
+      # Use periods to flatten the fields.
+      payload.merge!(
+        'exception.class' => exception.class.name,
+        'exception.message' => exception.message
+      )
+
+      if exception.backtrace
+        payload['exception.backtrace'] = Gitlab::Profiler.clean_backtrace(exception.backtrace)
+      end
+    end
+  end
+end

lib/gitlab/grape_logging/loggers/exception_logger.rb

@@ -11,19 +11,11 @@ module Gitlab
           # precedence so the logger never sees it. We need to
           # store and retrieve the exception from the environment.
           exception = request.env[::API::Helpers::API_EXCEPTION_ENV]
-          return {} unless exception.is_a?(Exception)
-          data = {
-            exception: {
-              class: exception.class.to_s,
-              message: exception.message
-            }
-          }
-
-          if exception.backtrace
-            data[:exception][:backtrace] = Gitlab::Profiler.clean_backtrace(exception.backtrace)
-          end
+          data = {}
+          return data unless exception.is_a?(Exception)
+          Gitlab::ExceptionLogFormatter.format!(exception, data)
           data
         end

lib/gitlab/import_export/relation_factory.rb

@@ -327,7 +327,12 @@ module Gitlab
       end
       def find_or_create_object!
-        return relation_class.find_or_create_by(project_id: @project.id) if UNIQUE_RELATIONS.include?(@relation_name)
+        if UNIQUE_RELATIONS.include?(@relation_name)
+          unique_relation_object = relation_class.find_or_create_by(project_id: @project.id)
+          unique_relation_object.assign_attributes(parsed_relation_hash)
+
+          return unique_relation_object
+        end
         # Can't use IDs as validation exists calling `group` or `project` attributes
         finder_hash = parsed_relation_hash.tap do |hash|

lib/quality/test_level.rb

@@ -36,6 +36,10 @@ module Quality
         workers
         elastic_integration
       ],
+      migration: %w[
+        migrations
+        lib/gitlab/background_migration
+      ],
       integration: %w[
         controllers
         mailers
@@ -62,6 +66,10 @@ module Quality
     def level_for(file_path)
       case file_path
+      # Detect migration first since some background migration tests are under
+      # spec/lib/gitlab/background_migration and tests under spec/lib are unit by default
+      when regexp(:migration)
+        :migration
       when regexp(:unit)
         :unit
       when regexp(:integration)

spec/fixtures/lib/gitlab/import_export/complex/project.json

@@ -7209,15 +7209,15 @@
     }
   ],
   "project_feature": {
-    "builds_access_level": 0,
+    "builds_access_level": 10,
     "created_at": "2014-12-26T09:26:45.000Z",
     "id": 2,
-    "issues_access_level": 0,
-    "merge_requests_access_level": 20,
+    "issues_access_level": 10,
+    "merge_requests_access_level": 10,
     "project_id": 4,
-    "snippets_access_level": 20,
+    "snippets_access_level": 10,
     "updated_at": "2016-09-23T11:58:28.000Z",
-    "wiki_access_level": 20
+    "wiki_access_level": 10
   },
   "custom_attributes": [
     {
@@ -7257,6 +7257,9 @@
       "image_url": "http://www.example.com"
     }
   ],
+  "ci_cd_settings": {
+    "group_runners_enabled": false
+  },
   "boards": [
     {
       "id": 29,

spec/helpers/projects/error_tracking_helper_spec.rb

@@ -75,4 +75,21 @@ describe Projects::ErrorTrackingHelper do
       end
     end
   end
+
+  describe '#error_details_data' do
+    let(:issue_id) { 1234 }
+    let(:route_params) { [project.owner, project, issue_id, { format: :json }] }
+    let(:details_path) { details_namespace_project_error_tracking_index_path(*route_params) }
+    let(:stack_trace_path) { stack_trace_namespace_project_error_tracking_index_path(*route_params) }
+
+    let(:result) { helper.error_details_data(project, issue_id) }
+
+    it 'returns the correct details path' do
+      expect(result['issue-details-path']).to eq details_path
+    end
+
+    it 'returns the correct stack trace path' do
+      expect(result['issue-stack-trace-path']).to eq stack_trace_path
+    end
+  end
 end