Merge branch '11-10-stable-prepare-rc4' into '11-10-stable'

Prepare 11.10.0-rc4 release

See merge request gitlab-org/gitlab-ce!27157

app/assets/javascripts/lib/utils/webpack.js

@@ -6,5 +6,11 @@ export function resetServiceWorkersPublicPath() {
   // see: https://webpack.js.org/guides/public-path/
   const relativeRootPath = (gon && gon.relative_url_root) || '';
   const webpackAssetPath = `${relativeRootPath}/assets/webpack/`;
+  __webpack_public_path__ = webpackAssetPath; // eslint-disable-line camelcase
+
+  // monaco-editor-webpack-plugin currently (incorrectly) references the
+  // public path as a property of `window`.  Once this is fixed upstream we
+  // can remove this line
+  // see: https://github.com/Microsoft/monaco-editor-webpack-plugin/pull/63
   window.__webpack_public_path__ = webpackAssetPath; // eslint-disable-line
 }

app/graphql/gitlab_schema.rb

 # frozen_string_literal: true
 class GitlabSchema < GraphQL::Schema
-  # Took our current most complicated query in use, issues.graphql,
-  # with a complexity of 19, and added a 20 point buffer to it.
+  # Currently an IntrospectionQuery has a complexity of 179.
   # These values will evolve over time.
-  DEFAULT_MAX_COMPLEXITY   = 40
-  AUTHENTICATED_COMPLEXITY = 50
-  ADMIN_COMPLEXITY         = 60
+  DEFAULT_MAX_COMPLEXITY   = 200
+  AUTHENTICATED_COMPLEXITY = 250
+  ADMIN_COMPLEXITY         = 300
   use BatchLoader::GraphQL
   use Gitlab::Graphql::Authorize

app/views/ci/status/_dropdown_graph_badge.html.haml

@@ -6,12 +6,12 @@
 - tooltip = "#{subject.name} - #{status.status_tooltip}"
 - if status.has_details?
-  = link_to status.details_path, class: 'mini-pipeline-graph-dropdown-item', data: { toggle: 'tooltip', title: tooltip, container: 'body' } do
+  = link_to status.details_path, class: 'mini-pipeline-graph-dropdown-item d-flex', data: { toggle: 'tooltip', title: tooltip, container: 'body' } do
     %span{ class: klass }= sprite_icon(status.icon)
     %span.ci-build-text.text-truncate.mw-70p.gl-pl-1= subject.name
 - else
-  .menu-item.mini-pipeline-graph-dropdown-item{ data: { toggle: 'tooltip', title: tooltip, container: 'body' } }
+  .menu-item.mini-pipeline-graph-dropdown-item.d-flex{ data: { toggle: 'tooltip', title: tooltip, container: 'body' } }
     %span{ class: klass }= sprite_icon(status.icon)
     %span.ci-build-text.text-truncate.mw-70p.gl-pl-1= subject.name

changelogs/unreleased/fix-pull-request-importer.yml

+---
+title: Improve performance of PR import
+merge_request: 27121
+author:
+type: performance

doc/ci/README.md

@@ -62,6 +62,7 @@ into more features:
 | [ChatOps](chatops/README.md)                                                                                              | Trigger CI jobs from chat, with results sent back to the channel.                          |
 | [Interactive web terminals](interactive_web_terminal/index.md)                                                            | Open an interactive web terminal to debug the running jobs.                                |
 | [Review Apps](review_apps/index.md)                                                                                       | Configure GitLab CI/CD to preview code changes in a per-branch basis.                      |
+| [Optimising GitLab for large repositories](large_repositories/index.md) | Useful tips on how to optimise GitLab and GitLab Runner for big repositories. |
 | [Deploy Boards](https://docs.gitlab.com/ee/user/project/deploy_boards.html) **[PREMIUM]**                                 | Check the current health and status of each CI/CD environment running on Kubernetes.       |
 | [GitLab CI/CD for external repositories](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/index.html) **[PREMIUM]** | Get the benefits of GitLab CI/CD combined with repositories in GitHub and BitBucket Cloud. |

doc/ci/large_repositories/index.md

+# Optimising GitLab for large repositories
+
+Large repositories consisting of more than 50k files in a worktree
+often require special consideration because of
+the time required to clone and check out.
+
+GitLab and GitLab Runner handle this scenario well
+but require optimised configuration to efficiently perform its
+set of operations.
+
+The general guidelines for handling big repositories are simple.
+Each guideline is described in more detail in the sections below:
+
+- Always fetch incrementally. Do not clone in a way that results in recreating all of the worktree.
+- Always use shallow clone to reduce data transfer. Be aware that this puts more burden
+  on GitLab instance due to higher CPU impact.
+- Control the clone directory if you heavily use a fork-based workflow.
+- Optimise `git clean` flags to ensure that you remove or keep data that might affect or speed-up your build.
+
+## Shallow cloning
+
+> Introduced in GitLab Runner 8.9.
+
+GitLab and GitLab Runner always perform a full clone by default.
+While it means that all changes from GitLab are received,
+it often results in receiving extra commit logs.
+
+Ideally, you should always use `GIT_DEPTH` with a small number
+like 10. This will instruct GitLab Runner to perform shallow clones.
+Shallow clones makes Git request only the latest set of changes for a given branch,
+up to desired number of commits as defined by the `GIT_DEPTH` variable.
+
+This significantly speeds up fetching of changes from Git repositories,
+especially if the repository has a very long backlog consisting of number
+of big files as we effectively reduce amount of data transfer.
+
+The following example makes GitLab Runner shallow clone to fetch only a given branch,
+it does not fetch any other branches nor tags.
+
+```yaml
+variables:
+  GIT_DEPTH: 10
+
+test:
+  script:
+    - ls -al
+```
+
+## Git strategy
+
+> Introduced in GitLab Runner 8.9.
+
+By default, GitLab is configured to always prefer the `GIT_STRATEGY: fetch` strategy.
+The `GIT_STRATEGY: fetch` strategy will re-use existing worktrees if found
+on disk. This is different to the `GIT_STRATEGY: clone` strategy
+as in case of clones, if a worktree is found, it is removed before clone.
+
+Usage of `fetch` is preferred because it reduces the amount of data to transfer and
+does not really impact the operations that you might do on a repository from CI.
+
+However, `fetch` does require access to the previous worktree. This works
+well when using the `shell` or `docker` executor because these
+try to preserve worktrees and try to re-use them by default.
+
+This does not work today for `kubernetes` executor and has limitations when using
+`docker+machine`. `kubernetes` executor today always clones into ephemeral directory.
+
+GitLab also offers the `GIT_STRATEGY: none` strategy. This disables any `fetch` and `checkout` commands
+done by GitLab, requiring you to do them.
+
+## Git clone path
+
+> Introduced in GitLab Runner 11.10.
+
+`GIT_CLONE_PATH` allows you to control where you clone your sources.
+This can have implications if you heavily use big repositories with fork workflow.
+
+Fork workflow from GitLab Runner's perspective is stored as a separate repository
+with separate worktree. That means that GitLab Runner cannot optimise the usage
+of worktrees and you might have to instruct GitLab Runner to use that.
+
+In such cases, ideally you want to make the GitLab Runner executor be used only used only
+for the given project and not shared across different projects to make this
+process more efficient.
+
+The `GIT_CLONE_PATH` has to be within the `$CI_BUILDS_DIR`. Currently,
+it is impossible to pick any path from disk.
+
+## Git clean flags
+
+> Introduced in GitLab Runner 11.10.
+
+`GIT_CLEAN_FLAGS` allows you to control whether or not you require
+the `git clean` command to be executed for each CI job.
+By default, GitLab ensures that you have your worktree on the given SHA,
+and that your repository is clean.
+
+`GIT_CLEAN_FLAGS` is disabled when set to `none`. On very big repositories, this
+might be desired because `git clean` is disk I/O intensive. Controlling that
+with `GIT_CLEAN_FLAGS: -ffdx -e .build/`, for example, allows you to control and
+disable removal of some directories within the worktree between subsequent runs,
+which can speed-up the incremental builds. This has the biggest effect
+if you re-use existing machines, and have an existing worktree that you can re-use
+for builds.
+
+For exact parameters accepted by `GIT_CLEAN_FLAGS`, see the documentation
+for [git clean](https://git-scm.com/docs/git-clean). The
+available parameters are dependent on Git version.
+
+## Fork-based workflow
+
+> Introduced in GitLab Runner 11.10.
+
+Following the guidelines above, lets imagine that we want to:
+
+- Optimise for a big project (more than 50k files in directory).
+- Use forks-based workflow for contributing.
+- Reuse existing worktrees. Have preconfigured runners that are pre-cloned with repositories.
+- Runner assigned only to project and all forks.
+
+Lets consider the following two examples, one using `shell` executor and
+other using `docker` executor.
+
+### `shell` executor example
+
+Lets assume that you have the following [config.toml](https://docs.gitlab.com/runner/configuration/advanced-configuration.html).
+
+```toml
+concurrent = 4
+
+[[runners]]
+  url = "GITLAB_URL"
+  token = "TOKEN"
+  executor = "shell"
+  builds_dir = "/builds"
+  cache_dir = "/cache"
+
+  [runners.custom_build_dir]
+    enabled = true
+```
+
+This `config.toml`:
+
+- Uses the `shell` executor,
+- Specifies a custom `/builds` directory where all clones will be stored.
+- Enables the ability to specify `GIT_CLONE_PATH`,
+- Runs at most 4 jobs at once.
+
+### `docker` executor example
+
+Lets assume that you have the following [config.toml](https://docs.gitlab.com/runner/configuration/advanced-configuration.html).
+
+```toml
+concurrent = 4
+
+[[runners]]
+  url = "GITLAB_URL"
+  token = "TOKEN"
+  executor = "docker"
+  builds_dir = "/builds"
+  cache_dir = "/cache"
+
+  [runners.docker]
+    volumes = ["/builds:/builds", "/cache:/cache"]
+```
+
+This `config.toml`:
+
+- Uses the `docker` executor,
+- Specifies a custom `/builds` directory on disk where all clones will be stored.
+   We host mount the `/builds` directory to make it reusable between subsequent runs
+   and be allowed to override the cloning strategy.
+- Doesn't enable the ability to specify `GIT_CLONE_PATH` as it is enabled by default.
+- Runs at most 4 jobs at once.
+
+### Our `.gitlab-ci.yml`
+
+Once we have the executor configured, we need to fine tune our `.gitlab-ci.yml`.
+
+Our pipeline will be most performant if we use the following `.gitlab-ci.yml`:
+
+```yaml
+variables:
+  GIT_DEPTH: 10
+  GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_NAME
+
+build:
+  script: ls -al
+```
+
+The above configures a:
+
+- Shallow clone of 10, to speed up subsequent `git fetch` commands.
+- Custom clone path to make it possible to re-use worktrees between parent project and all forks
+  because we use the same clone path for all forks.
+
+Why use `$CI_CONCURRENT_ID`? The main reason is to ensure that worktrees used are not conflicting
+between projects. The `$CI_CONCURRENT_ID` represents a unique identifier within the given executor,
+so as long as we use it to construct the path, it is guaranteed that this directory will not conflict
+with other concurrent jobs running.
+
+### Store custom clone options in `config.toml`
+
+Ideally, all job-related configuration should be stored in `.gitlab-ci.yml`.
+However, sometimes it is desirable to make these schemes part of Runner configuration.
+
+In the above example of Forks, making this configuration discoverable for users may be preferred,
+but this brings administrative overhead as the `.gitlab-ci.yml` needs to be updated for each branch.
+In such cases, it might be desirable to keep the `.gitlab-ci.yml` clone path agnostic, but make it
+a configuration of Runner.
+
+We can extend our [config.toml](https://docs.gitlab.com/runner/configuration/advanced-configuration.html)
+with the following specification that will be used by Runner if `.gitlab-ci.yml` will not override it:
+
+```toml
+concurrent = 4
+
+[[runners]]
+  url = "GITLAB_URL"
+  token = "TOKEN"
+  executor = "docker"
+  builds_dir = "/builds"
+  cache_dir = "/cache"
+
+  environment = [
+    "GIT_DEPTH=10",
+    "GIT_CLONE_PATH=$CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_NAME"
+  ]
+
+  [runners.docker]
+    volumes = ["/builds:/builds", "/cache:/cache"]
+```
+
+This makes the cloning configuration to be part of given Runner,
+and does not require us to update each `.gitlab-ci.yml`.

doc/user/project/issues/index.md

 # Issues
-The GitLab Issue Tracker is an advanced and complete tool
-for tracking the evolution of a new idea or the process
-of solving a problem.
-It allows you, your team, and your collaborators to share
-and discuss proposals before and while implementing them.
-GitLab Issues and the GitLab Issue Tracker are available in all
-[GitLab Products](https://about.gitlab.com/pricing/) as
-part of the [GitLab Workflow](https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/).
-## Use cases
-Issues can have endless applications. Just to exemplify, these are
-some cases for which creating issues are most used:
+Issues are the fundamental medium for collaborating on ideas and planning work in GitLab.
+## Overview
+The GitLab issue tracker is an advanced tool for collaboratively developing ideas, solving problems, and planning work.
+Issues can allow you, your team, and your collaborators to share and discuss proposals before and during their implementation.
+However, they can be used for a variety of other purposes, customized to your needs and workflow.
+Issues are always associated with a specific project, but if you have multiple projects in a group,
+you can also view all the issues collectively at the group level.
+
+**Common use cases include:**
 - Discussing the implementation of a new idea
-- Submitting feature proposals
-- Asking questions
-- Reporting bugs and malfunction
-- Obtaining support
+- Tracking tasks and work status
+- Accepting feature proposals, questions, support requests, or bug reports
 - Elaborating new code implementations
 See also the blog post "[Always start a discussion with an issue](https://about.gitlab.com/2016/03/03/start-with-an-issue/)".
-### Keep private things private
-
-For instance, let's assume you have a public project but want to start a discussion on something
-you don't want to be public. With [Confidential Issues](#confidential-issues),
-you can discuss private matters among the project members, and still keep
-your project public, open to collaboration.
-
-### Streamline collaboration
-
-With [Multiple Assignees for Issues](https://docs.gitlab.com/ee/user/project/issues/multiple_assignees_for_issues.html),
-available in [GitLab Starter](https://about.gitlab.com/pricing/)
-you can streamline collaboration and allow shared responsibilities to be clearly displayed.
-All assignees are shown across your workflows and receive notifications (as they
-would as single assignees), simplifying communication and ownership.
-
-### Consistent collaboration
-
-Create [issue templates](#issue-templates) to make collaboration consistent and
-containing all information you need. For example, you can create a template
-for feature proposals and another one for bug reports.
-
-## Issue Tracker
-
-The Issue Tracker is the collection of opened and closed issues created in a project.
-It is available for all projects, from the moment the project is created.
-
-Find the issue tracker by navigating to your **Project's homepage** > **Issues**.
-
-### Issues per project
-
-When you access your project's issues, GitLab will present them in a list,
-and you can use the tabs available to quickly filter by open and closed issues.
-
-![Project issues list view](img/project_issues_list_view.png)
-
-You can also [search and filter](../../search/index.md#issues-and-merge-requests-per-project) the results more deeply with GitLab's search capacities.
-
-### Issues per group
-
-View issues in all projects in the group, including all projects of all descendant subgroups of the group. Navigate to **Group > Issues** to view these issues. This view also has the open and closed issues tabs.
-
-![Group Issues list view](img/group_issues_list_view.png)
-
-## GitLab Issues Functionalities
-
-The image bellow illustrates how an issue looks like:
+## Parts of an issue
+
+Issues contain a variety of content and metadata, enabling a large range of flexibility in how they are used. Each issue can contain the following attributes, though some items may remain unset.
+
+<table class="borderless-table fixed-table">
+<tr>
+    <td>
+        <ul>
+            <li>Content</li>
+            <ul>
+                <li>Title</li>
+                <li>Description and tasks</li>
+                <li>Comments and other activity</li>
+            </ul>
+            <li>People</li>
+            <ul>
+                <li>Author</li>
+                <li>Assignee(s)</li>
+            </ul>
+            <li>State</li>
+            <ul>
+                <li>Status (open/closed)</li>
+                <li>Confidentiality</li>
+                <li>Tasks (completed vs. outstanding)</li>
+            </ul>
+        </ul>
+    </td>
+    <td>
+        <ul>
+            <li>Planning and tracking</li>
+            <ul>
+                <li>Milestone</li>
+                <li>Due date</li>
+                <li>Weight</li>
+                <li>Time tracking</li>
+                <li>Labels</li>
+                <li>Votes</li>
+                <li>Reaction emoji</li>
+                <li>Linked issues</li>
+                <li>Assigned epic</li>
+                <li>Unique issue number and URL</li>
+            </ul>
+       </ul>
+    </td>
+</tr>
+</table>
+
+## Viewing and managing issues
+
+While you can view and manage the full detail of an issue at its URL, you can also work with multiple issues at a time using the Issues List, Issue Boards, Epics **[ULTIMATE]**, and issue references.
+
+### Issue page
 ![Issue view](img/issues_main_view.png)
-Learn more about it on the [GitLab Issues Functionalities documentation](issues_functionalities.md).
-
-## New issue
-Read through the [documentation on creating issues](create_new_issue.md).
-## Closing issues
-Learn distinct ways to [close issues](closing_issues.md) in GitLab.
-
-## Moving issues
-
-Read through the [documentation on moving issues](moving_issues.md).
-
-## Deleting issues
-Read through the [documentation on deleting issues](deleting_issues.md)
-## Create a merge request from an issue
-Learn more about it on the [GitLab Issues Functionalities documentation](issues_functionalities.md#18-new-merge-request).
-## Search for an issue
-Learn how to [find an issue](../../search/index.md) by searching for and filtering them.
-## Advanced features
-### Confidential Issues
-Whenever you want to keep the discussion presented in a
-issue within your team only, you can make that
-[issue confidential](confidential_issues.md). Even if your project
-is public, that issue will be preserved. The browser will
-respond with a 404 error whenever someone who is not a project
-member with at least [Reporter level](../../permissions.md#project-members-permissions) tries to
-access that issue's URL.
-Learn more about them on the [confidential issues documentation](confidential_issues.md).
-### Issue templates
-Create templates for every new issue. They will be available from
-the dropdown menu **Choose a template** when you create a new issue:
-![issue template](img/issue_template.png)
-Learn more about them on the [issue templates documentation](../../project/description_templates.md#creating-issue-templates).
+On an issue’s page, you can view all aspects of the issue, and you can also modify them if you you have the necessary [permissions](../../permissions.md).
+For more information, see the [Issue Functionalities](issues_functionalities.md) page.
+### Issues list
+![Project issues list view](img/project_issues_list_view.png)
+On the Issues List, you can view all issues in the current project, or from multiple projects when opening the Issues List from the higher-level group context. Filter the issue list by [any search query](../../search/index.md#issues-and-merge-requests-per-project) and/or specific metadata, such as label(s), assignees(s), status, and more. From this view, you can also make certain changes [in bulk](../bulk_editing.md) to the displayed issues.
+For more information, see the [Issue Functioinalities](issues_functionalities.md) page.
+### Issue boards
+![Issue board](img/issue_board.png)
+Issue boards are Kanban boards with columns that display issues based on their labels or their assignees**[PREMIUM]**. They offer the flexibility to manage issues using highly customizable workflows.
+You can reorder issues within a column, or drag an issue card to another column; its associated label or assignee will change to match that of the new column. The entire board can also be filtered to only include issues from a certain milestone or an overarching label.
+For more information, see the [Issue Boards](../issue_board.md) page.
+### Epics **[ULTIMATE]**
+Epics let you manage your portfolio of projects more efficiently and with less effort by tracking groups of issues that share a theme, across projects and milestones.
+For more information, see the [Epics](https://docs.gitlab.com/ee/user/group/epics/) page.
+### Related issues **[STARTER]**
+You can mark two issues as related, so that when viewing each one, the other is always listed in its Related Issues section. This can help display important context, such as past work, dependencies, or duplicates.
+For more information, see [Related Issues](https://docs.gitlab.com/ee/user/project/issues/related_issues.html).
 ### Crosslinking issues
-Learn more about [crosslinking](crosslinking_issues.md) issues and merge requests.
-
-### Issue Board
-
-The [GitLab Issue Board](https://about.gitlab.com/features/issueboard/) is a way to
-enhance your workflow by organizing and prioritizing issues in GitLab.
-
-![Issue board](img/issue_board.png)
-
-Find GitLab Issue Boards by navigating to your **Project's Dashboard** > **Issues** > **Board**.
-
-Read through the documentation for [Issue Boards](../issue_board.md)
-to find out more about this feature.
-
-With [GitLab Starter](https://about.gitlab.com/pricing/), you can also
-create various boards per project with [Multiple Issue Boards](../issue_board.html#multiple-issue-boards-starter).
-
-### Import Issues from CSV
-
-You can import a CSV file containing issue titles and descriptions to create
-a batch of issues simultaneously.
-
-When you navigate to the Issues list page, an import button is displayed.
-
-For further details, see [Importing issues from CSV](csv_import.md)
-
-### External Issue Tracker
-
-Alternatively to GitLab's built-in Issue Tracker, you can also use an [external
-tracker](../../../integration/external-issue-tracker.md) such as Jira, Redmine,
-YouTrack, or Bugzilla.
-
-### Issue API
-See the [API documentation](../../../api/issues.md).
-### Bulk editing issues
-See the [bulk editing issues](../../project/bulk_editing.md) page.
-### Similar issues
-See the [similar issues](similar_issues.md) page.
+When you reference an issue from another issue or merge request by including its URL or ID, the referenced issue displays a message in the Activity stream about the reference, with a link to the other issue or MR.
+For more information, see [Crosslinking issues](crosslinking_issues.md).
+## Issue actions
+- [Create an issue](create_new_issue.md)
+- [Create an issue from a template](../../project/description_templates.md#using-the-templates)
+- [Close an issue](closing_issues.md)
+- [Move an issue](moving_issues.md)
+- [Delete an issue](deleting_issues.md)
+- [Create a merge request from an issue](issues_functionalities.md#18-new-merge-request)
+## Advanced issue management
+- [Bulk edit issues](../bulk_editing.md) - From the Issues List, select multiple issues in order to change their status, assignee, milestone, or labels in bulk.
+- [Import issues](csv_import.md)
+- [Export issues](https://docs.gitlab.com/ee/user/project/issues/csv_export.html) **[STARTER]**
+- [Issues API](../../../api/issues.md)
+- Configure an [external issue tracker](../../../integration/external-issue-tracker.md) such as Jira, Redmine,
+or Bugzilla.

doc/user/project/issues/issues_functionalities.md

-# GitLab Issues Functionalities
+# Issue Data and Actions
 Please read through the [GitLab Issue Documentation](index.md) for an overview on GitLab Issues.
-## Issues Functionalities
+## Parts of an Issue
 The image below illustrates what an issue looks like:

lib/gitlab/import/merge_request_helpers.rb

@@ -22,7 +22,7 @@ module Gitlab
           # additional work that is strictly necessary.
           merge_request_id = insert_and_return_id(attributes, project.merge_requests)
-          merge_request = project.merge_requests.reload.find(merge_request_id)
+          merge_request = project.merge_requests.reset.find(merge_request_id)
           [merge_request, false]
         end

spec/fixtures/api/graphql/introspection.graphql

+# pulled from GraphiQL query
+query IntrospectionQuery {
+  __schema {
+    queryType { name }
+    mutationType { name }
+    subscriptionType { name }
+    types {
+      ...FullType
+    }
+    directives {
+      name
+      description
+      locations
+      args {
+        ...InputValue
+      }
+    }
+  }
+}
+
+fragment FullType on __Type {
+  kind
+  name
+  description
+  fields(includeDeprecated: true) {
+    name
+    description
+    args {
+      ...InputValue
+    }
+    type {
+      ...TypeRef
+    }
+    isDeprecated
+    deprecationReason
+  }
+  inputFields {
+    ...InputValue
+  }
+  interfaces {
+    ...TypeRef
+  }
+  enumValues(includeDeprecated: true) {
+    name
+    description
+    isDeprecated
+    deprecationReason
+  }
+  possibleTypes {
+    ...TypeRef
+  }
+}
+
+fragment InputValue on __InputValue {
+  name
+  description
+  type { ...TypeRef }
+  defaultValue
+}
+
+fragment TypeRef on __Type {
+  kind
+  name
+  ofType {
+    kind
+    name
+    ofType {
+      kind
+      name
+      ofType {
+        kind
+        name
+        ofType {
+          kind
+          name
+          ofType {
+            kind
+            name
+            ofType {
+              kind
+              name
+              ofType {
+                kind
+                name
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+}

spec/lib/gitlab/import/merge_request_helpers_spec.rb

+# frozen_string_literal: true
+
+require 'spec_helper'
+
+describe Gitlab::Import::MergeRequestHelpers, type: :helper do
+  set(:project) { create(:project, :repository) }
+  set(:user) { create(:user) }
+
+  describe '.create_merge_request_without_hooks' do
+    let(:iid) { 42 }
+
+    let(:attributes) do
+      {
+        iid: iid,
+        title: 'My Pull Request',
+        description: 'This is my pull request',
+        source_project_id: project.id,
+        target_project_id: project.id,
+        source_branch: 'master-42',
+        target_branch: 'master',
+        state: :merged,
+        author_id: user.id,
+        assignee_id: user.id
+      }
+    end
+
+    subject { helper.create_merge_request_without_hooks(project, attributes, iid) }
+
+    context 'when merge request does not exist' do
+      it 'returns a new object' do
+        expect(subject.first).not_to be_nil
+        expect(subject.second).to eq(false)
+      end
+
+      it 'does load all existing objects' do
+        5.times do |iid|
+          MergeRequest.create!(
+            attributes.merge(iid: iid, source_branch: iid.to_s))
+        end
+
+        # does ensure that we only load object twice
+        # 1. by #insert_and_return_id
+        # 2. by project.merge_requests.find
+        expect_any_instance_of(MergeRequest).to receive(:attributes)
+          .twice.times.and_call_original
+
+        expect(subject.first).not_to be_nil
+        expect(subject.second).to eq(false)
+      end
+    end
+
+    context 'when merge request does exist' do
+      before do
+        MergeRequest.create!(attributes)
+      end
+
+      it 'returns an existing object' do
+        expect(subject.first).not_to be_nil
+        expect(subject.second).to eq(true)
+      end
+    end
+
+    context 'when project is deleted' do
+      before do
+        project.delete
+      end
+
+      it 'returns an existing object' do
+        expect(subject.first).to be_nil
+      end
+    end
+  end
+end

spec/requests/api/graphql/gitlab_schema_spec.rb

@@ -3,14 +3,24 @@ require 'spec_helper'
 describe 'GitlabSchema configurations' do
   include GraphqlHelpers
-  let(:project) { create(:project, :repository) }
-  let!(:query)  { graphql_query_for('project', 'fullPath' => project.full_path) }
-  it 'shows an error if complexity it too high' do
+  it 'shows an error if complexity is too high' do
+    project = create(:project, :repository)
+    query   = graphql_query_for('project', { 'fullPath' => project.full_path }, "id\nname\ndescription")
     allow(GitlabSchema).to receive(:max_query_complexity).and_return 1
     post_graphql(query, current_user: nil)
     expect(graphql_errors.first['message']).to include('which exceeds max complexity of 1')
   end
+
+  context 'when IntrospectionQuery' do
+    it 'is not too complex' do
+      query = File.read(Rails.root.join('spec/fixtures/api/graphql/introspection.graphql'))
+
+      post_graphql(query, current_user: nil)
+
+      expect(graphql_errors).to be_nil
+    end
+  end
 end