[ci skip] Merge branch 'master' into 3776-ci-view-for-sast

* master: (102 commits)
  Refactor DR docs
  Remove unneeded images from old Geo docs
  Point to final doc location
  Use exec_query wrapper for ProjectAuthorization.roles_stats
  [Geo] Add logging when create a temporary repository
  Docs: Update all articles with the new layout (metadata from the frontmatter)
  Avoid slow File Lock checks when not used
  Fix Error 500 when viewing a commit with a GPG signature in Geo
  Remember assignee when moving an issue
  Add changelog entry
  Allow oxford commas and spaces before commas in MR issue closing pattern.
  Don't cache a nil repository root ref to prevent caching issues
  Merge branch '43345-spec-requests-api-project_import_spec-rb-fails' into 'master'
  Add back database changes for Ci::Build
  Revert "Merge branch 'expired-ci-artifacts' into 'master'"
  Fix order dependencies in some specs
  migrate admin:users:* to static bundle
  correct for missing break statement in dispatcher.js
  alias create and update actions to new and edit
  migrate projects:merge_requests:edit to static bundle
  ...

.gitlab-ci.yml

@@ -291,7 +291,7 @@ retrieve-tests-metadata:
 
 ee-files-location-check:
   <<: *dedicated-runner
-  stage: prepare
+  stage: test
   before_script: []
   cache: {}
   script:

CHANGELOG-EE.md

 Please view this file on the master branch, on stable branches it's out of date.
 
+## 10.4.4 (2018-02-16)
+
+### Fixed (4 changes)
+
+- Handle empty event timestamp and larger memory units. !4206
+- Geo: Reset force_redownload flag after successful sync.
+- [Geo] Fix redownload repository recovery when there is not local repo at all.
+- Allow project to be set up to push to and pull from same mirror.
+
+
 ## 10.4.3 (2018-02-05)
 
 ### Security (1 change)

CHANGELOG.md

@@ -2,6 +2,25 @@
 documentation](doc/development/changelog.md) for instructions on adding your own
 entry.
 
+## 10.4.4 (2018-02-16)
+
+### Security (1 change)
+
+- Update nokogiri to 1.8.2. !16807
+
+### Fixed (9 changes)
+
+- Fix 500 error when loading a merge request with an invalid comment. !16795
+- Cleanup new branch/merge request form in issues. !16854
+- Fix GitLab import leaving group_id on ProjectLabel. !16877
+- Fix forking projects when no restricted visibility levels are defined applicationwide. !16881
+- Resolve PrepareUntrackedUploads PostgreSQL syntax error. !17019
+- Fixed error 500 when removing an identity with synced attributes and visiting the profile page. !17054
+- Validate user namespace before saving so that errors persist on model.
+- LDAP Person no longer throws exception on invalid entry.
+- Fix JIRA not working when a trailing slash is included.
+
+
 ## 10.4.3 (2018-02-05)
 
 ### Security (4 changes)

app/assets/javascripts/ide/monaco_loader.js

@@ -6,6 +6,11 @@ monacoContext.require.config({
   },
 });
 
+// ignore CDN config and use local assets path for service worker which cannot be cross-domain
+const relativeRootPath = (gon && gon.relative_url_root) || '';
+const monacoPath = `${relativeRootPath}/assets/webpack/monaco-editor/vs`;
+window.MonacoEnvironment = { getWorkerUrl: () => `${monacoPath}/base/worker/workerMain.js` };
+
 // eslint-disable-next-line no-underscore-dangle
 window.__monaco_context__ = monacoContext;
 export default monacoContext.require;

app/assets/javascripts/pages/admin/jobs/index/index.js

 import Vue from 'vue';
-
 import Translate from '~/vue_shared/translate';
-
 import stopJobsModal from './components/stop_jobs_modal.vue';
 
 Vue.use(Translate);
 
-export default () => {
+document.addEventListener('DOMContentLoaded', () => {
   const stopJobsButton = document.getElementById('stop-jobs-button');
   if (stopJobsButton) {
     // eslint-disable-next-line no-new
@@ -27,4 +25,4 @@ export default () => {
       },
     });
   }
-};
+});

app/assets/javascripts/pages/admin/projects/index/index.js

@@ -5,7 +5,7 @@ import csrf from '~/lib/utils/csrf';
 
 import deleteProjectModal from './components/delete_project_modal.vue';
 
-export default () => {
+document.addEventListener('DOMContentLoaded', () => {
   Vue.use(Translate);
 
   const deleteProjectModalEl = document.getElementById('delete-project-modal');
@@ -34,4 +34,4 @@ export default () => {
       deleteModal.projectName = buttonProps.projectName;
     }
   });
-};
+});

app/assets/javascripts/pages/admin/users/shared/index.js → app/assets/javascripts/pages/admin/users/index.js

@@ -5,7 +5,7 @@ import csrf from '~/lib/utils/csrf';
 
 import deleteUserModal from './components/delete_user_modal.vue';
 
-export default () => {
+document.addEventListener('DOMContentLoaded', () => {
   Vue.use(Translate);
 
   const deleteUserModalEl = document.getElementById('delete-user-modal');
@@ -40,4 +40,4 @@ export default () => {
       deleteModal.username = buttonProps.username;
     }
   });
-};
+});

app/assets/javascripts/pages/dashboard/issues/index.js

 import projectSelect from '~/project_select';
 import initLegacyFilters from '~/init_legacy_filters';
 
-export default () => {
+document.addEventListener('DOMContentLoaded', () => {
   projectSelect();
   initLegacyFilters();
-};
+});

app/assets/javascripts/pages/dashboard/merge_requests/index.js

 import projectSelect from '~/project_select';
 import initLegacyFilters from '~/init_legacy_filters';
 
-export default () => {
+document.addEventListener('DOMContentLoaded', () => {
   projectSelect();
   initLegacyFilters();
-};
+});

app/assets/javascripts/pages/dashboard/milestones/show/index.js

 import Milestone from '~/milestone';
 import Sidebar from '~/right_sidebar';
 
-export default () => {
+document.addEventListener('DOMContentLoaded', () => {
   new Milestone(); // eslint-disable-line no-new
   new Sidebar(); // eslint-disable-line no-new
-};
+});

app/assets/javascripts/pages/dashboard/projects/index.js

 import ProjectsList from '~/projects_list';
 
-export default () => new ProjectsList();
+document.addEventListener('DOMContentLoaded', () => new ProjectsList());

app/assets/javascripts/pages/dashboard/todos/index/index.js

 import Todos from './todos';
 
-export default () => new Todos();
+document.addEventListener('DOMContentLoaded', () => new Todos());

app/assets/javascripts/pages/explore/groups/index.js

@@ -2,7 +2,7 @@ import GroupsList from '~/groups_list';
 import Landing from '~/landing';
 import initGroupsList from '../../../groups';
 
-export default function () {
+document.addEventListener('DOMContentLoaded', () => {
   new GroupsList(); // eslint-disable-line no-new
   initGroupsList();
   const landingElement = document.querySelector('.js-explore-groups-landing');
@@ -13,4 +13,4 @@ export default function () {
     'explore_groups_landing_dismissed',
   );
   exploreGroupsLanding.toggle();
-}
+});

app/assets/javascripts/pages/explore/projects/index.js

 import ProjectsList from '~/projects_list';
 
-export default () => new ProjectsList();
+document.addEventListener('DOMContentLoaded', () => new ProjectsList());

app/assets/javascripts/pages/groups/issues/index.js

@@ -3,10 +3,10 @@ import initFilteredSearch from '~/pages/search/init_filtered_search';
 import { FILTERED_SEARCH } from '~/pages/constants';
 import FilteredSearchTokenKeysIssues from 'ee/filtered_search/filtered_search_token_keys_issues';
 
-export default () => {
+document.addEventListener('DOMContentLoaded', () => {
   initFilteredSearch({
     page: FILTERED_SEARCH.ISSUES,
     filteredSearchTokenKeys: FilteredSearchTokenKeysIssues,
   });
   projectSelect();
-};
+});

app/assets/javascripts/pages/groups/merge_requests/index.js

@@ -2,9 +2,9 @@ import projectSelect from '~/project_select';
 import initFilteredSearch from '~/pages/search/init_filtered_search';
 import { FILTERED_SEARCH } from '~/pages/constants';
 
-export default () => {
+document.addEventListener('DOMContentLoaded', () => {
   initFilteredSearch({
     page: FILTERED_SEARCH.MERGE_REQUESTS,
   });
   projectSelect();
-};
+});

app/assets/javascripts/pages/groups/milestones/edit/index.js

 import initForm from '../../../../shared/milestones/form';
 
-export default () => initForm(false);
+document.addEventListener('DOMContentLoaded', () => initForm(false));

app/assets/javascripts/pages/groups/milestones/new/index.js

 import initForm from '../../../../shared/milestones/form';
 
-export default () => initForm(false);
+document.addEventListener('DOMContentLoaded', () => initForm(false));

app/assets/javascripts/pages/groups/milestones/show/index.js

 import initMilestonesShow from '~/pages/milestones/shared/init_milestones_show';
 
-export default initMilestonesShow;
+document.addEventListener('DOMContentLoaded', initMilestonesShow);

app/assets/javascripts/pages/projects/branches/index/index.js

 import AjaxLoadingSpinner from '~/ajax_loading_spinner';
 import DeleteModal from '~/branches/branches_delete_modal';
 
-export default () => {
+document.addEventListener('DOMContentLoaded', () => {
   AjaxLoadingSpinner.init();
   new DeleteModal(); // eslint-disable-line no-new
-};
+});

app/assets/javascripts/pages/projects/branches/new/index.js

 import NewBranchForm from '~/new_branch_form';
 
-export default () => new NewBranchForm($('.js-create-branch-form'), JSON.parse(document.getElementById('availableRefs').innerHTML));
+document.addEventListener('DOMContentLoaded', () => (
+  new NewBranchForm($('.js-create-branch-form'), JSON.parse(document.getElementById('availableRefs').innerHTML))
+));

app/assets/javascripts/pages/projects/compare/show/index.js

 import Diff from '~/diff';
 import initChangesDropdown from '~/init_changes_dropdown';
 
-export default () => {
+document.addEventListener('DOMContentLoaded', () => {
   new Diff(); // eslint-disable-line no-new
   const paddingTop = 16;
   initChangesDropdown(document.querySelector('.navbar-gitlab').offsetHeight - paddingTop);
-};
+});

app/assets/javascripts/pages/projects/environments/metrics/index.js

 import monitoringBundle from '~/monitoring/monitoring_bundle';
 
-export default monitoringBundle;
+document.addEventListener('DOMContentLoaded', monitoringBundle);

app/assets/javascripts/pages/projects/issues/edit/index.js

 import initForm from '../form';
 
-export default () => {
-  initForm();
-};
+document.addEventListener('DOMContentLoaded', initForm);

app/assets/javascripts/pages/projects/issues/new/index.js

 import initForm from '../form';
 
-export default () => {
-  initForm();
-};
+document.addEventListener('DOMContentLoaded', initForm);

app/assets/javascripts/pages/projects/merge_requests/creations/diffs/index.js → app/assets/javascripts/pages/projects/merge_requests/creations/index.js

 import initMergeRequest from '~/pages/projects/merge_requests/init_merge_request';
 
-export default initMergeRequest;
+document.addEventListener('DOMContentLoaded', initMergeRequest);

app/assets/javascripts/pages/projects/merge_requests/creations/new/index.js

 import Compare from '~/compare';
 import MergeRequest from '~/merge_request';
 
-export default () => {
+document.addEventListener('DOMContentLoaded', () => {
   const mrNewCompareNode = document.querySelector('.js-merge-request-new-compare');
   if (mrNewCompareNode) {
     new Compare({ // eslint-disable-line no-new
@@ -15,4 +15,4 @@ export default () => {
       action: mrNewSubmitNode.dataset.mrSubmitAction,
     });
   }
-};
+});

app/assets/javascripts/pages/projects/merge_requests/edit/index.js

 import initMergeRequest from '~/pages/projects/merge_requests/init_merge_request';
 
-export default initMergeRequest;
+document.addEventListener('DOMContentLoaded', initMergeRequest);

app/assets/javascripts/pages/projects/milestones/edit/index.js

 import initForm from '../../../../shared/milestones/form';
 
-export default () => initForm();
+document.addEventListener('DOMContentLoaded', () => initForm());

app/assets/javascripts/pages/projects/milestones/index/index.js

 import milestones from '~/pages/milestones/shared';
 
-export default milestones;
+document.addEventListener('DOMContentLoaded', milestones);

app/assets/javascripts/pages/projects/milestones/new/index.js

 import initForm from '../../../../shared/milestones/form';
 
-export default () => initForm();
+document.addEventListener('DOMContentLoaded', () => initForm());

app/assets/javascripts/pages/projects/milestones/show/index.js

 import initMilestonesShow from '~/pages/milestones/shared/init_milestones_show';
 import milestones from '~/pages/milestones/shared';
 
-export default () => {
+document.addEventListener('DOMContentLoaded', () => {
   initMilestonesShow();
   milestones();
-};
+});

app/assets/javascripts/pages/projects/services/edit/index.js

 import IntegrationSettingsForm from '~/integrations/integration_settings_form';
+import PrometheusMetrics from '~/prometheus_metrics/prometheus_metrics';
 
 export default () => {
+  const prometheusSettingsWrapper = document.querySelector('.js-prometheus-metrics-monitoring');
   const integrationSettingsForm = new IntegrationSettingsForm('.js-integration-settings-form');
   integrationSettingsForm.init();
+
+  if (prometheusSettingsWrapper) {
+    const prometheusMetrics = new PrometheusMetrics('.js-prometheus-metrics-monitoring');
+    prometheusMetrics.loadActiveMetrics();
+  }
 };

app/assets/javascripts/prometheus_metrics/index.js

-import PrometheusMetrics from './prometheus_metrics';
-
-$(() => {
-  const prometheusMetrics = new PrometheusMetrics('.js-prometheus-metrics-monitoring');
-  prometheusMetrics.loadActiveMetrics();
-});

app/assets/javascripts/vue_merge_request_widget/components/states/mr_widget_auto_merge_failed.vue

@@ -44,7 +44,10 @@
         type="button"
         class="btn btn-xs btn-default"
       >
-        <loading-icon v-if="isRefreshing" />
+        <loading-icon
+          v-if="isRefreshing"
+          :inline="true"
+        />
         {{ s__("mrWidget|Refresh") }}
       </button>
     </div>

app/controllers/admin/dashboard_controller.rb

 class Admin::DashboardController < Admin::ApplicationController
+  prepend ::EE::Admin::DashboardController
+
   def index
     @projects = Project.order_id_desc.without_deleted.with_route.limit(10)
     @users = User.order_id_desc.limit(10)

app/helpers/webpack_helper.rb

@@ -7,17 +7,24 @@ module WebpackHelper
 
   def webpack_controller_bundle_tags
     bundles = []
-    segments = [*controller.controller_path.split('/'), controller.action_name].compact
 
-    until segments.empty?
+    action = case controller.action_name
+             when 'create' then 'new'
+             when 'update' then 'edit'
+             else controller.action_name
+             end
+
+    route = [*controller.controller_path.split('/'), action].compact
+
+    until route.empty?
       begin
-        asset_paths = gitlab_webpack_asset_paths("pages.#{segments.join('.')}", extension: 'js')
+        asset_paths = gitlab_webpack_asset_paths("pages.#{route.join('.')}", extension: 'js')
         bundles.unshift(*asset_paths)
       rescue Webpack::Rails::Manifest::EntryPointMissingError
         # no bundle exists for this path
       end
 
-      segments.pop
+      route.pop
     end
 
     javascript_include_tag(*bundles)

app/models/ci/build.rb

@@ -44,41 +44,12 @@ module Ci
 
     scope :unstarted, ->() { where(runner_id: nil) }
     scope :ignore_failures, ->() { where(allow_failure: false) }
-
-    # This convoluted mess is because we need to handle two cases of
-    # artifact files during the migration. And a simple OR clause
-    # makes it impossible to optimize.
-
-    # Instead we want to use UNION ALL and do two carefully
-    # constructed disjoint queries. But Rails cannot handle UNION or
-    # UNION ALL queries so we do the query in a subquery and wrap it
-    # in an otherwise redundant WHERE IN query (IN is fine for
-    # non-null columns).
-
-    # This should all be ripped out when the migration is finished and
-    # replaced with just the new storage to avoid the extra work.
-
     scope :with_artifacts, ->() do
-      old = Ci::Build.select(:id).where(%q[artifacts_file <> ''])
-      new = Ci::Build.select(:id).where(%q[(artifacts_file IS NULL OR artifacts_file = '') AND EXISTS (?)],
-                                        Ci::JobArtifact.select(1).where('ci_builds.id = ci_job_artifacts.job_id'))
-      where('ci_builds.id IN (? UNION ALL ?)', old, new)
+      where('(artifacts_file IS NOT NULL AND artifacts_file <> ?) OR EXISTS (?)',
+        '', Ci::JobArtifact.select(1).where('ci_builds.id = ci_job_artifacts.job_id'))
     end
-
-    scope :with_artifacts_not_expired, ->() do
-      old = Ci::Build.select(:id).where(%q[artifacts_file <> '' AND (artifacts_expire_at IS NULL OR artifacts_expire_at > ?)], Time.now)
-      new = Ci::Build.select(:id).where(%q[(artifacts_file IS NULL OR artifacts_file = '') AND EXISTS (?)],
-                                        Ci::JobArtifact.select(1).where('ci_builds.id = ci_job_artifacts.job_id AND (expire_at IS NULL OR expire_at > ?)', Time.now))
-      where('ci_builds.id IN (? UNION ALL ?)', old, new)
-    end
-
-    scope :with_expired_artifacts, ->() do
-      old = Ci::Build.select(:id).where(%q[artifacts_file <> '' AND artifacts_expire_at < ?], Time.now)
-      new = Ci::Build.select(:id).where(%q[(artifacts_file IS NULL OR artifacts_file = '') AND EXISTS (?)],
-                                        Ci::JobArtifact.select(1).where('ci_builds.id = ci_job_artifacts.job_id AND expire_at < ?', Time.now))
-      where('ci_builds.id IN (? UNION ALL ?)', old, new)
-    end
-
+    scope :with_artifacts_not_expired, ->() { with_artifacts.where('artifacts_expire_at IS NULL OR artifacts_expire_at > ?', Time.now) }
+    scope :with_expired_artifacts, ->() { with_artifacts.where('artifacts_expire_at < ?', Time.now) }
     scope :last_month, ->() { where('created_at > ?', Date.today - 1.month) }
     scope :manual_actions, ->() { where(when: :manual, status: COMPLETED_STATUSES + [:manual]) }
     scope :ref_protected, -> { where(protected: true) }

app/models/key.rb

@@ -36,9 +36,8 @@ class Key < ActiveRecord::Base
   after_destroy :refresh_user_cache
 
   def key=(value)
-    value&.delete!("\n\r")
-    value.strip! unless value.blank?
-    write_attribute(:key, value)
+    write_attribute(:key, value.present? ? Gitlab::SSHPublicKey.sanitize(value) : nil)
+
     @public_key = nil
   end
 
@@ -100,7 +99,7 @@ class Key < ActiveRecord::Base
   def generate_fingerprint
     self.fingerprint = nil
 
-    return unless self.key.present?
+    return unless public_key.valid?
 
     self.fingerprint = public_key.fingerprint
   end

app/models/project_authorization.rb

 class ProjectAuthorization < ActiveRecord::Base
+  prepend ::EE::ProjectAuthorization
+
   belongs_to :user
   belongs_to :project
 

app/models/repository.rb

@@ -499,12 +499,8 @@ class Repository
   end
 
   def root_ref
-    if raw_repository
-      raw_repository.root_ref
-    else
-      # When the repo does not exist we raise this error so no data is cached.
-      raise Gitlab::Git::Repository::NoRepository
-    end
+    # When the repo does not exist, or there is no root ref, we raise this error so no data is cached.
+    raw_repository&.root_ref or raise Gitlab::Git::Repository::NoRepository # rubocop:disable Style/AndOr
   end
   cache_method :root_ref
 

app/services/issues/move_service.rb

 module Issues
   class MoveService < Issues::BaseService
+    prepend ::EE::Issues::MoveService
+
     MoveError = Class.new(StandardError)
 
     def execute(issue, new_project)
@@ -48,7 +50,8 @@ module Issues
       new_params = { id: nil, iid: nil, label_ids: cloneable_label_ids,
                      milestone_id: cloneable_milestone_id,
                      project: @new_project, author: @old_issue.author,
-                     description: rewrite_content(@old_issue.description) }
+                     description: rewrite_content(@old_issue.description),
+                     assignee_ids: @old_issue.assignee_ids }
 
       new_params = @old_issue.serializable_hash.symbolize_keys.merge(new_params)
       CreateService.new(@new_project, @current_user, new_params).execute

app/views/admin/dashboard/index.html.haml

@@ -23,6 +23,9 @@
               %h3.text-center
                 Users:
                 = number_with_delimiter(User.count)
+            -# EE specific
+            .text-center
+              = link_to 'Users statistics', admin_dashboard_stats_path
             %hr
             = link_to 'New user', new_admin_user_path, class: "btn btn-new"
       .col-sm-4

app/views/projects/services/prometheus/_show.html.haml

-- content_for :page_specific_javascripts do
-  = webpack_bundle_tag('prometheus_metrics')
-
 .row.prepend-top-default.append-bottom-default.prometheus-metrics-monitoring.js-prometheus-metrics-monitoring
   .col-lg-3
     %h4.prepend-top-0

changelogs/unreleased-ee/4871-gcp-geo-nodes-cannot-move-original-repository.yml

----
-title: "[Geo] Fix redownload repository recovery when there is not local repo at all"
-merge_request:
-author:
-type: fixed

changelogs/unreleased-ee/4920-count-of-users-by-role-in-admin.yml

+---
+title: Add users stats page for admin area with per role amount
+merge_request: 4539
+author:
+type: changed

changelogs/unreleased/sh-fix-jira-trailing-slash.yml → changelogs/unreleased-ee/move-epic-issue.yml

 ---
-title: Fix JIRA not working when a trailing slash is included
+title: Update epic issue reference when moving an issue
 merge_request:
 author:
 type: fixed

changelogs/unreleased/17500-mr-multiple-issues-oxford-comma.yml

+---
+title: Update issue closing pattern to allow variations in punctuation
+merge_request: 17198
+author: Vicky Chijwani
+type: changed

changelogs/unreleased/40552-sanitize-extra-blank-spaces-used-when-uploading-a-ssh-key.yml

+---
+title: Sanitize extra blank spaces used when uploading a SSH key
+merge_request: 40552
+author:
+type: fixed

changelogs/unreleased/41899-api-endpoint-for-importing-a-project-export.yml

+---
+title: API endpoint for importing a project export
+merge_request: 17025
+author:
+type: added

changelogs/unreleased/remove_ldap_person_validation.yml → changelogs/unreleased/41949-move.yml

 ---
-title: LDAP Person no longer throws exception on invalid entry
+title: Remember assignee when moving an issue
 merge_request:
 author:
 type: fixed

changelogs/unreleased/42160-error-500-loading-merge-request-undefined-method-index-for-nil-nilclass.yml

----
-title: Fix 500 error when loading a merge request with an invalid comment
-merge_request: 16795
-author:
-type: fixed

changelogs/unreleased/42591-update-nokogiri.yml

----
-title: Update nokogiri to 1.8.2
-merge_request: 16807
-author:
-type: security

changelogs/unreleased/42641-monaco-service-workers-do-not-work-with-cdn-enabled.yml

+---
+title: Fix monaco editor features which were incompatable with GitLab CDN settings
+merge_request: 17021
+author:
+type: fixed

changelogs/unreleased/42696-gitlab-import-leaves-group_id-on-projectlabel.yml

----
-title: Fix GitLab import leaving group_id on ProjectLabel
-merge_request: 16877
-author:
-type: fixed

changelogs/unreleased/asciidoc_inter_document_cross_references.yml

+---
+title: Asciidoc now support inter-document cross references between files in repository
+merge_request: 17125
+author: Turo Soisenniemi
+type: changed

changelogs/unreleased/bvl-fix-500-on-fork-without-restricted-visibility-levels.yml

----
-title: Fix forking projects when no restricted visibility levels are defined applicationwide
-merge_request: 16881
-author:
-type: fixed

changelogs/unreleased-ee/dm-remote-mirror-url-availability.yml → changelogs/unreleased/dm-dont-cache-nil-root-ref.yml

 ---
-title: Allow project to be set up to push to and pull from same mirror
+title: Don't cache a nil repository root ref to prevent caching issues
 merge_request:
 author:
 type: fixed

changelogs/unreleased/dm-user-namespace-route-path-validation.yml

----
-title: Validate user namespace before saving so that errors persist on model
-merge_request:
-author:
-type: fixed

changelogs/unreleased/expired-ci-artifacts.yml

----
-title: Change SQL for expired artifacts to use new ci_job_artifacts.expire_at
-merge_request: 16578
-author:
-type: performance

changelogs/unreleased/fj-37528-error-after-disabling-ldap.yml

----
-title: Fixed error 500 when removing an identity with synced attributes and visiting
-  the profile page
-merge_request: 17054
-author:
-type: fixed

changelogs/unreleased-ee/4211-document-process-for-bring-a-demoted-primary-back-docs.yml → changelogs/unreleased/fl-refresh-btn.yml

 ---
-title: 'Geo: Reset force_redownload flag after successful sync'
+title: Show loading button inline in refresh button in MR widget
 merge_request:
 author:
 type: fixed

changelogs/unreleased/mk-fix-no-untracked-upload-files-error.yml

----
-title: Resolve PrepareUntrackedUploads PostgreSQL syntax error
-merge_request: 17019
-author:
-type: fixed

changelogs/unreleased/sh-fix-geo-error-500-gpg-commit.yml

+---
+title: Fix Error 500 when viewing a commit with a GPG signature in Geo
+merge_request:
+author:
+type: fixed

changelogs/unreleased/winh-new-branch-dropdown-style.yml

----
-title: Cleanup new branch/merge request form in issues
-merge_request: 16854
-author:
-type: fixed

config/initializers/1_settings.rb

@@ -294,7 +294,7 @@ Settings.gitlab['signup_enabled'] ||= true if Settings.gitlab['signup_enabled'].
 Settings.gitlab['signin_enabled'] ||= true if Settings.gitlab['signin_enabled'].nil?
 Settings.gitlab['restricted_visibility_levels'] = Settings.__send__(:verify_constant_array, Gitlab::VisibilityLevel, Settings.gitlab['restricted_visibility_levels'], [])
 Settings.gitlab['username_changing_enabled'] = true if Settings.gitlab['username_changing_enabled'].nil?
-Settings.gitlab['issue_closing_pattern'] = '((?:[Cc]los(?:e[sd]?|ing)|[Ff]ix(?:e[sd]|ing)?|[Rr]esolv(?:e[sd]?|ing)|[Ii]mplement(?:s|ed|ing)?)(:?) +(?:(?:issues? +)?%{issue_ref}(?:(?:, *| +and +)?)|([A-Z][A-Z0-9_]+-\d+))+)' if Settings.gitlab['issue_closing_pattern'].nil?
+Settings.gitlab['issue_closing_pattern'] = '((?:[Cc]los(?:e[sd]?|ing)|[Ff]ix(?:e[sd]|ing)?|[Rr]esolv(?:e[sd]?|ing)|[Ii]mplement(?:s|ed|ing)?)(:?) +(?:(?:issues? +)?%{issue_ref}(?:(?: *,? +and +| *, *)?)|([A-Z][A-Z0-9_]+-\d+))+)' if Settings.gitlab['issue_closing_pattern'].nil?
 Settings.gitlab['default_projects_features'] ||= {}
 Settings.gitlab['webhook_timeout'] ||= 10
 Settings.gitlab['max_attachment_size'] ||= 10

config/routes/admin.rb

@@ -138,6 +138,8 @@ namespace :admin do
       get  :status
     end
   end
+
+  get '/dashboard/stats', to: 'dashboard#stats'
   ## EE-specific
 
   resources :labels

config/webpack.config.js

@@ -27,11 +27,11 @@ var pageEntries = glob.sync('pages/**/index.js', { cwd: path.join(ROOT_PATH, 'ap
 
 // filter out entries currently imported dynamically in dispatcher.js
 var dispatcher = fs.readFileSync(path.join(ROOT_PATH, 'app/assets/javascripts/dispatcher.js')).toString();
-var dispatcherChunks = dispatcher.match(/(?!import\('.\/)pages\/[^']+/g);
+var dispatcherChunks = dispatcher.match(/(?!import\(')\.\/pages\/[^']+/g);
 
 pageEntries.forEach(( path ) => {
   let chunkPath = path.replace(/\/index\.js$/, '');
-  if (!dispatcherChunks.includes(chunkPath)) {
+  if (!dispatcherChunks.includes('./' + chunkPath)) {
     let chunkName = chunkPath.replace(/\//g, '.');
     autoEntries[chunkName] = './' + path;
   }
@@ -90,7 +90,6 @@ var config = {
     pipelines_details:    './pipelines/pipeline_details_bundle.js',
     profile:              './profile/profile_bundle.js',
     project_import_gl:    './projects/project_import_gitlab_project.js',
-    prometheus_metrics:   './prometheus_metrics',
     protected_branches:   './protected_branches',
     ee_protected_branches: 'ee/protected_branches',
     protected_tags:       './protected_tags',

doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md

-# How to configure LDAP with GitLab CE
+---
+author: Chris Wilson
+author_gitlab: MrChrisW
+level: intermediary
+article_type: admin guide
+date: 2017-05-03
+---
 
-> **[Article Type](../../../development/writing_documentation.html#types-of-technical-articles):** admin guide ||
-> **Level:** intermediary ||
-> **Author:** [Chris Wilson](https://gitlab.com/MrChrisW) ||
-> **Publication date:** 2017-05-03
+# How to configure LDAP with GitLab CE
 
 ## Introduction
 

doc/administration/auth/how_to_configure_ldap_gitlab_ee/index.md

-# How to configure LDAP with GitLab EE
+---
+author: Chris Wilson
+author_gitlab: MrChrisW
+level: intermediary
+article_type: admin guide
+date: 2017-05-03
+---
 
-> **[Article Type](../../../development/writing_documentation.html#types-of-technical-articles):** admin guide ||
-> **Level:** intermediary ||
-> **Author:** [Chris Wilson](https://gitlab.com/MrChrisW) ||
-> **Publication date:** 2017/05/03
+# How to configure LDAP with GitLab EE
 
 ## Introduction
 

doc/administration/geo/disaster_recovery/bring_primary_back.md

+# Bring a demoted primary node back online
+
+After a failover, it is possible to fail back to the demoted primary to
+restore your original configuration. This process consists of two steps:
+
+1. Making the old primary a secondary
+1. Promoting a secondary to a primary
+
+## Configure the former primary to be a secondary
+
+Since the former primary will be out of sync with the current primary, the first
+step is to bring the former primary up to date. There is one downside though,
+some uploads and repositories that have been deleted during an idle period of a
+primary node, will not be deleted from the disk but the overall sync will be
+much faster. As an alternative, you can set up a
+[GitLab instance from scratch](../replication/index.md#setup-instructions) to
+workaround this downside.
+
+To bring the former primary up to date:
+
+1. SSH into the former primary that has fallen behind
+1. Make sure all the services are up:
+
+    ```bash
+    sudo gitlab-ctl start
+    ```
+
+    NOTE: **Note:** If you [disabled the primary permanently](index.md#step-2-permanently-disable-the-primary),
+    you need to undo those steps now. For Debian/Ubuntu you just need to run
+    `sudo systemctl enable gitlab-runsvdir`. For CentOS 6, you need to install
+    the GitLab instance from scratch and setup it as a secondary node by
+    following the [setup instructions](../replication/index.md#setup-instructions).
+    In this case you don't need to follow the next step.
+
+1. [Setup database replication](../replication/database.md). Note that in this
+   case, primary refers to the current primary, and secondary refers to the
+   former primary.
+
+If you have lost your original primary, follow the
+[setup instructions](../replication/index.md#setup-instructions) to set up a new secondary.
+
+## Promote the secondary to primary
+
+When the initial replication is complete and the primary and secondary are
+closely in sync, you can do a [planned failover](planned_failover.md).
+
+## Restore the secondary node
+
+If your objective is to have two nodes again, you need to bring your secondary
+node back online as well by repeating the first step
+([configure the former primary to be a secondary](#configure-the-former-primary-to-be-a-secondary))
+for the secondary node.

doc/administration/geo/disaster_recovery/index.md

+# Disaster Recovery
+
+Geo replicates your database and your Git repositories. We will
+support and replicate more data in the future, that will enable you to
+failover with minimal effort, in a disaster situation.
+
+See [Geo current limitations](../replication/index.md#current-limitations)
+for more information.
+
+## Promoting secondary Geo replica in single-secondary configurations
+
+We don't currently provide an automated way to promote a Geo replica and do a
+failover, but you can do it manually if you have `root` access to the machine.
+
+This process promotes a secondary Geo replica to a primary. To regain
+geographical redundancy as quickly as possible, you should add a new secondary
+immediately after following these instructions.
+
+### Step 1. Allow replication to finish if possible
+
+If the secondary is still replicating data from the primary, follow
+[the planned failover docs](planned_failover.md) as closely as possible in
+order to avoid unnecessary data loss.
+
+### Step 2. Permanently disable the primary
+
+CAUTION: **Warning:**
+If a primary goes offline, there may be data saved on the primary
+that has not been replicated to the secondary. This data should be treated
+as lost if you proceed.
+
+If an outage on your primary happens, you should do everything possible to
+avoid a split-brain situation where writes can occur to two different GitLab
+instances, complicating recovery efforts. So to prepare for the failover, we
+must disable the primary.
+
+1. SSH into your **primary** to stop and disable GitLab, if possible:
+
+    ```bash
+    sudo gitlab-ctl stop
+    ```
+
+    Prevent GitLab from starting up again if the server unexpectedly reboots:
+
+    ```bash
+    sudo systemctl disable gitlab-runsvdir
+    ```
+
+    On some operating systems such as CentOS 6, an easy way to prevent GitLab
+    from being started if the machine reboots isn't available
+    (see [Omnibus issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3058)).
+    It may be safest to uninstall the GitLab package completely:
+
+    ```bash
+    yum remove gitlab-ee
+    ```
+
+1. If you do not have SSH access to your primary, take the machine offline and
+    prevent it from rebooting by any means at your disposal.
+    Since there are many ways you may prefer to accomplish this, we will avoid a
+    single recommendation. You may need to:
+      - Reconfigure the load balancers
+      - Change DNS records (e.g., point the primary DNS record to the secondary node in order to stop usage of the primary)
+      - Stop the virtual servers
+      - Block traffic through a firewall
+      - Revoke object storage permissions from the primary
+      - Physically disconnect a machine
+
+### Step 3. Promoting a secondary Geo replica
+
+1. SSH in to your **secondary** and login as root:
+
+    ```bash
+    sudo -i
+    ```
+
+1. Edit `/etc/gitlab/gitlab.rb` to reflect its new status as primary by
+   removing the following line:
+
+    ```ruby
+    ## REMOVE THIS LINE
+    geo_secondary_role['enable'] = true
+    ```
+
+    A new secondary should not be added at this time. If you want to add a new
+    secondary, do this after you have completed the entire process of promoting
+    the secondary to the primary.
+
+1. Promote the secondary to primary. Execute:
+
+    ```bash
+    gitlab-ctl promote-to-primary-node
+    ```
+
+1. Verify you can connect to the newly promoted primary using the URL used
+   previously for the secondary.
+1. Success! The secondary has now been promoted to primary.
+
+### Step 4. (Optional) Updating the primary domain DNS record
+
+Updating the DNS records for the primary domain to point to the secondary
+will prevent the need to update all references to the primary domain to the
+secondary domain, like changing Git remotes and API URLs.
+
+1. SSH in to your **secondary** and login as root:
+
+    ```bash
+    sudo -i
+    ```
+
+1. Update the primary domain's DNS record. After updating the primary domain's
+   DNS records to point to the secondary, edit `/etc/gitlab/gitlab.rb` on the
+   secondary to reflect the new URL:
+
+    ```ruby
+    # Change the existing external_url configuration
+    external_url 'https://gitlab.example.com'
+    ```
+
+1. Reconfigure the secondary node for the change to take effect:
+
+    ```bash
+    gitlab-ctl reconfigure
+    ```
+
+1. Execute the command below to update the newly promoted primary node URL:
+
+    ```bash
+    gitlab-rake geo:update_primary_node_url
+    ```
+
+    This command will use the changed `external_url` configuration defined
+    in `/etc/gitlab/gitlab.rb`.
+
+1. Verify you can connect to the newly promoted primary using the primary URL.
+   If you updated the DNS records for the primary domain, these changes may
+   not have yet propagated depending on the previous DNS records TTL.
+
+### Step 5. (Optional) Add secondary Geo replicas to a promoted primary
+
+Promoting a secondary to primary using the process above does not enable
+Geo on the new primary.
+
+To bring a new secondary online, follow the
+[Geo setup instructions](../replication/index.md#setup-instructions).
+
+## Promoting secondary Geo replica in multi-secondary configurations
+
+CAUTION: **Caution:**
+Disaster Recovery for multi-secondary configurations is in
+**Alpha** development. Do not use this as your only Disaster Recovery
+strategy as you may lose data.
+
+Disaster Recovery does not yet support systems with multiple
+secondary Geo replicas (e.g., one primary and two or more secondaries). We are
+working on it, see [#4284](https://gitlab.com/gitlab-org/gitlab-ee/issues/4284)
+for details.
+
+## Troubleshooting
+
+### I followed the disaster recovery instructions and now two-factor auth is broken!
+
+The setup instructions for Geo prior to 10.5 failed to replicate the
+`otp_key_base` secret, which is used to encrypt the two-factor authentication
+secrets stored in the database. If it differs between primary and secondary
+nodes, users with two-factor authentication enabled won't be able to log in
+after a failover.
+
+If you still have access to the old primary node, you can follow the
+instructions in the
+[Upgrading to GitLab 10.5](../replication/updating_the_geo_nodes.md#upgrading-to-gitlab-105)
+section to resolve the error. Otherwise, the secret is lost and you'll need to
+[reset two-factor authentication for all users](../../../security/two_factor_authentication.md#disabling-2fa-for-everyone).

doc/administration/geo/disaster_recovery/planned_failover.md

+# Disaster recovery for planned failover
+
+A planned failover is similar to a disaster recovery scenario, except you are able
+to notify users of the maintenance window, and allow data to finish replicating to
+secondaries.
+
+Please read this entire document as well as [Disaster Recovery](index.md)
+before proceeding.
+
+## Notify users of scheduled maintenance
+
+On the primary, navigate to **Admin Area > Messages**, add a broadcast message.
+You can check under **Admin Area > Geo Nodes** to estimate how long it will
+take to finish syncing. An example message would be:
+
+>
+A scheduled maintenance will take place at XX:XX UTC. We expect it to take
+less than 1 hour.
+
+On the secondary, you may need to clear the cache for the broadcast message
+to show up.
+
+## Block primary traffic
+
+At the scheduled time, using your cloud provider or your node's firewall, block
+HTTP and SSH traffic to/from the primary except for your IP and the secondary's
+IP.
+
+## Allow replication to finish as much as possible
+
+1. On the secondary, navigate to **Admin Area > Geo Nodes** and wait until all
+   replication progress is 100% on the secondary "Current node".
+1. Navigate to **Admin Area > Monitoring > Background Jobs > Queues** and wait
+   until the "geo" queues drop ideally to 0.
+
+## Promote the secondary
+
+Finally, follow the [Disaster Recovery docs](index.md) to promote the secondary
+to a primary.

doc/administration/geo/replication/configuration.md

+# Geo configuration
+
+>**Note:**
+This is the documentation for the Omnibus GitLab packages. For installations
+from source, follow the [**Geo nodes configuration for installations
+from source**](configuration_source.md) guide.
+
+## Configuring a new secondary node
+
+>**Note:**
+This is the final step in setting up a secondary Geo node. Stages of the
+setup process must be completed in the documented order.
+Before attempting the steps in this stage, [complete all prior stages](index.md#using-omnibus-gitlab).
+
+The basic steps of configuring a secondary node are to replicate required
+configurations between the primary and the secondaries; to configure a tracking
+database on each secondary; and to start GitLab on the secondary node.
+
+You are encouraged to first read through all the steps before executing them
+in your testing/production environment.
+
+>**Notes:**
+- **Do not** setup any custom authentication in the secondary nodes, this will be
+  handled by the primary node.
+- **Do not** add anything in the secondaries Geo nodes admin area
+  (**Admin Area ➔ Geo Nodes**). This is handled solely by the primary node.
+
+### Step 1. Manually replicate secret GitLab values
+
+GitLab stores a number of secret values in the `/etc/gitlab/gitlab-secrets.json`
+file which *must* match between the primary and secondary nodes. Until there is
+a means of automatically replicating these between nodes (see
+[issue #3789](https://gitlab.com/gitlab-org/gitlab-ee/issues/3789)), they must
+be manually replicated to the secondary.
+
+1. SSH into the **primary** node, and execute the command below:
+
+    ```bash
+    sudo cat /etc/gitlab/gitlab-secrets.json
+    ```
+
+    This will display the secrets that need to be replicated, in JSON format.
+
+1. SSH into the **secondary** node and login as the `root` user:
+
+    ```
+    sudo -i
+    ```
+
+1. Make a backup of any existing secrets:
+
+    ```bash
+    mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`
+    ```
+
+1. Copy `/etc/gitlab/gitlab-secrets.json` from the primary to the secondary, or
+   copy-and-paste the file contents between nodes:
+
+    ```bash
+    sudo editor /etc/gitlab/gitlab-secrets.json
+
+    # paste the output of the `cat` command you ran on the primary
+    # save and exit
+    ```
+
+1. Ensure the file permissions are correct:
+
+    ```bash
+    chown root:root /etc/gitlab/gitlab-secrets.json
+    chmod 0600 /etc/gitlab/gitlab-secrets.json
+    ```
+
+1. Reconfigure the secondary node for the change to take effect:
+
+    ```
+    gitlab-ctl reconfigure
+    ```
+
+Once reconfigured, the secondary will automatically start
+replicating missing data from the primary in a process known as backfill.
+Meanwhile, the primary node will start to notify the secondary of any changes, so
+that the secondary can act on those notifications immediately.
+
+Make sure the secondary instance is
+running and accessible. You can login to the secondary node
+with the same credentials as used in the primary.
+
+### Step 2. Manually replicate primary SSH host keys
+
+GitLab integrates with the system-installed SSH daemon, designating a user
+(typically named git) through which all access requests are handled.
+
+In a [Disaster Recovery](../disaster_recovery/index.md) situation, GitLab system
+administrators will promote a secondary Geo replica to a primary and they can
+update the DNS records for the primary domain to point to the secondary to prevent
+the need to update all references to the primary domain to the secondary domain,
+like changing Git remotes and API URLs.
+
+This will cause all SSH requests to the newly promoted primary node from
+failing due to SSH host key mismatch. To prevent this, the primary SSH host
+keys must be manually replicated to the secondary node.
+
+1. SSH into the **secondary** node and login as the `root` user:
+
+    ```
+    sudo -i
+    ```
+
+1. Make a backup of any existing SSH host keys:
+
+    ```bash
+    find /etc/ssh -iname ssh_host_* -exec cp {} {}.backup.`date +%F` \;
+    ```
+
+1. SSH into the **primary** node, and execute the command below:
+
+    ```bash
+    sudo find /etc/ssh -iname ssh_host_* -not -iname '*.pub'
+    ```
+
+1. For each file in that list replace the file from the primary node to
+   the **same** location on your **secondary** node.
+
+1. On your **secondary** node, ensure the file permissions are correct:
+
+    ```bash
+    chown root:root /etc/ssh/ssh_host_*
+    chmod 0600 /etc/ssh/ssh_host_*
+    ```
+
+1. Regenerate the public keys from the private keys:
+
+    ```bash
+    find /etc/ssh -iname ssh_host_* -not -iname '*.backup*' -exec sh -c 'ssh-keygen -y -f "{}" > "{}.pub"' \;
+    ```
+
+1. Restart sshd:
+
+    ```bash
+    service ssh restart
+    ```
+
+### Step 3. (Optional) Enabling hashed storage (from GitLab 10.0)
+
+>**Warning**
+Hashed storage is in **Beta**. It is not considered production-ready. See
+[Hashed Storage](../../repository_storage_types.md) for more detail,
+and for the latest updates, check
+[infrastructure issue #2821](https://gitlab.com/gitlab-com/infrastructure/issues/2821).
+
+Using hashed storage significantly improves Geo replication - project and group
+renames no longer require synchronization between nodes.
+
+1. Visit the **primary** node's **Admin Area ➔ Settings**
+   (`/admin/application_settings`) in your browser
+1. In the `Repository Storages` section, check `Create new projects using hashed storage paths`:
+
+    ![](img/hashed_storage.png)
+
+### Step 4. (Optional) Configuring the secondary to trust the primary
+
+You can safely skip this step if your primary uses a CA-issued HTTPS certificate.
+
+If your primary is using a self-signed certificate for *HTTPS* support, you will
+need to add that certificate to the secondary's trust store. Retrieve the
+certificate from the primary and follow
+[these instructions](https://docs.gitlab.com/omnibus/settings/ssl.html)
+on the secondary.
+
+### Step 5. Enable Git access over HTTP/HTTPS
+
+Geo synchronizes repositories over HTTP/HTTPS, and therefore requires this clone
+method to be enabled. Navigate to **Admin Area ➔ Settings**
+(`/admin/application_settings`) on the primary node, and set
+`Enabled Git access protocols` to `Both SSH and HTTP(S)` or `Only HTTP(S)`.
+
+### Step 6. Verify proper functioning of the secondary node
+
+Congratulations! Your secondary geo node is now configured!
+
+You can login to the secondary node with the same credentials you used on the
+primary. Visit the secondary node's **Admin Area ➔ Geo Nodes**
+(`/admin/geo_nodes`) in your browser to check if it's correctly identified as a
+secondary Geo node and if Geo is enabled.
+
+The initial replication, or 'backfill', will probably still be in progress. You
+can monitor the synchronization process on each geo node from the primary
+node's Geo Nodes dashboard in your browser.
+
+![Geo dashboard](img/geo_node_dashboard.png)
+
+If your installation isn't working properly, check the
+[troubleshooting document](troubleshooting.md).
+
+The two most obvious issues that can become apparent in the dashboard are:
+
+1. Database replication not working well
+1. Instance to instance notification not working. In that case, it can be
+   something of the following:
+     - You are using a custom certificate or custom CA (see the
+       [troubleshooting document](troubleshooting.md))
+     - The instance is firewalled (check your firewall rules)
+
+Please note that disabling a secondary node will stop the sync process.
+
+Please note that if `git_data_dirs` is customized on the primary for multiple
+repository shards you must duplicate the same configuration on the secondary.
+
+Point your users to the ["Using a Geo Server" guide](using_a_geo_server.md).
+
+Currently, this is what is synced:
+
+* Git repositories
+* Wikis
+* LFS objects
+* Issues, merge requests, snippets, and comment attachments
+* Users, groups, and project avatars
+
+## Selective synchronization
+
+Geo supports selective synchronization, which allows admins to choose
+which projects should be synchronized by secondary nodes.
+
+It is important to note that selective synchronization does not:
+
+1. Restrict permissions from secondary nodes.
+1. Hide project metadata from secondary nodes.
+  * Since Geo currently relies on PostgreSQL replication, all project metadata
+    gets replicated to secondary nodes, but repositories that have not been
+    selected will be empty.
+1. Reduce the number of events generated for the Geo event log
+  * The primary generates events as long as any secondaries are present.
+    Selective synchronization restrictions are implemented on the secondaries,
+    not the primary.
+
+A subset of projects can be chosen, either by group or by storage shard. The
+former is ideal for replicating data belonging to a subset of users, while the
+latter is more suited to progressively rolling out Geo to a large GitLab
+instance.
+
+## Upgrading Geo
+
+See the [updating the Geo nodes document](updating_the_geo_nodes.md).
+
+## Troubleshooting
+
+See the [troubleshooting document](troubleshooting.md).

doc/administration/geo/replication/configuration_source.md

+# Geo configuration
+
+>**Note:**
+This is the documentation for installations from source. For installations
+using the Omnibus GitLab packages, follow the
+[**Omnibus Geo nodes configuration**](configuration.md) guide.
+
+## Configuring a new secondary node
+
+>**Note:**
+This is the final step in setting up a secondary Geo node. Stages of the setup
+process must be completed in the documented order. Before attempting the steps
+in this stage, [complete all prior stages](index.md#using-gitlab-installed-from-source).
+
+The basic steps of configuring a secondary node are to replicate required
+configurations between the primary and the secondaries; to configure a tracking
+database on each secondary; and to start GitLab on the secondary node.
+
+You are encouraged to first read through all the steps before executing them
+in your testing/production environment.
+
+
+>**Notes:**
+- **Do not** setup any custom authentication in the secondary nodes, this will be
+  handled by the primary node.
+- **Do not** add anything in the secondaries Geo nodes admin area
+  (**Admin Area ➔ Geo Nodes**). This is handled solely by the primary node.
+
+### Step 1. Manually replicate secret GitLab values
+
+GitLab stores a number of secret values in the `/home/git/gitlab/config/secrets.yml`
+file which *must* match between the primary and secondary nodes. Until there is
+a means of automatically replicating these between nodes (see
+[issue #3789](https://gitlab.com/gitlab-org/gitlab-ee/issues/3789)), they must
+be manually replicated to the secondary.
+
+1. SSH into the **primary** node, and execute the command below:
+
+    ```bash
+    sudo cat /home/git/gitlab/config/secrets.yml
+    ```
+
+    This will display the secrets that need to be replicated, in YAML format.
+
+1. SSH into the **secondary** node and login as the `git` user:
+
+    ```bash
+    sudo -i -u git
+    ```
+
+1. Make a backup of any existing secrets:
+
+    ```bash
+    mv /home/git/gitlab/config/secrets.yml /home/git/gitlab/config/secrets.yml.`date +%F`
+    ```
+
+1. Copy `/home/git/gitlab/config/secrets.yml` from the primary to the secondary, or
+   copy-and-paste the file contents between nodes:
+
+    ```bash
+    sudo editor /home/git/gitlab/config/secrets.yml
+
+    # paste the output of the `cat` command you ran on the primary
+    # save and exit
+    ```
+
+1. Ensure the file permissions are correct:
+
+    ```bash
+    chown git:git /home/git/gitlab/config/secrets.yml
+    chmod 0600 /home/git/gitlab/config/secrets.yml
+    ```
+
+1. Restart GitLab for the changes to take effect:
+
+    ```bash
+    service gitlab restart
+    ```
+
+Once restarted, the secondary will automatically start replicating missing data
+from the primary in a process known as backfill. Meanwhile, the primary node
+will start to notify the secondary of any changes, so that the secondary can
+act on those notifications immediately.
+
+Make sure the secondary instance is running and accessible. You can login to
+the secondary node with the same credentials as used in the primary.
+
+### Step 2. Manually replicate primary SSH host keys
+
+Read [Manually replicate primary SSH host keys](configuration.md#step-2-manually-replicate-primary-ssh-host-keys)
+
+### Step 3. (Optional) Enabling hashed storage (from GitLab 10.0)
+
+Read [Enabling Hashed Storage](configuration.md#step-3-optional-enabling-hashed-storage-from-gitlab-10-0)
+
+### Step 4. (Optional) Configuring the secondary to trust the primary
+
+You can safely skip this step if your primary uses a CA-issued HTTPS certificate.
+
+If your primary is using a self-signed certificate for *HTTPS* support, you will
+need to add that certificate to the secondary's trust store. Retrieve the
+certificate from the primary and follow your distribution's instructions for
+adding it to the secondary's trust store. In Debian/Ubuntu, for example, with a
+certificate file of `primary.geo.example.com.crt`, you would follow these steps:
+
+```
+sudo -i
+cp primary.geo.example.com.crt /usr/local/share/ca-certificates
+update-ca-certificates
+```
+
+### Step 5. Enable Git access over HTTP/HTTPS
+
+Geo synchronizes repositories over HTTP/HTTPS, and therefore requires this clone
+method to be enabled. Navigate to **Admin Area ➔ Settings**
+(`/admin/application_settings`) on the primary node, and set
+`Enabled Git access protocols` to `Both SSH and HTTP(S)` or `Only HTTP(S)`.
+
+### Step 6. Verify proper functioning of the secondary node
+
+Read [Verify proper functioning of the secondary node](configuration.md#step-6-verify-proper-functioning-of-the-secondary-node).
+
+
+## Selective synchronization
+
+Read [Selective synchronization](configuration.md#selective-synchronization).
+
+## Troubleshooting
+
+Read the [troubleshooting document](troubleshooting.md).

doc/administration/geo/replication/docker_registry.md

+# Docker Registry for a secondary node
+
+You can setup a [Docker Registry](https://docs.docker.com/registry/) on your
+secondary Geo node that mirrors the one on the primary Geo node.
+
+## Storage support
+
+CAUTION: **Warning:**
+If you use [local storage](../../container_registry.md#container-registry-storage-driver)
+for the Container Registry you **cannot** replicate it to the secondary Geo node.
+
+Docker Registry currently supports a few types of storages. If you choose a
+distributed storage (`azure`, `gcs`, `s3`, `swift`, or `oss`) for your Docker
+Registry on a primary Geo node, you can use the same storage for a secondary
+Docker Registry as well. For more information, read the
+[Load balancing considerations](https://docs.docker.com/registry/deploying/#load-balancing-considerations)
+when deploying the Registry, and how to setup the storage driver for GitLab's
+integrated [Container Registry](../../container_registry.md#container-registry-storage-driver).
+
+[ee]: https://about.gitlab.com/products/

doc/administration/geo/replication/faq.md

+# Geo Frequently Asked Questions
+
+## Can I use Geo in a disaster recovery situation?
+
+Yes, but there are limitations to what we replicate (see
+[What data is replicated to a secondary node?](#what-data-is-replicated-to-a-secondary-node)).
+
+Read the documentation for [Disaster Recovery](../disaster_recovery/index.md).
+
+## What data is replicated to a secondary node?
+
+We currently replicate project repositories, LFS objects, generated
+attachments / avatars and the whole database. This means user accounts,
+issues, merge requests, groups, project data, etc., will be available for
+query. We currently don't replicate artifact data (`shared/folder`).
+
+## Can I git push to a secondary node?
+
+No. All writing operations (this includes `git push`) must be done in your
+primary node.
+
+## How long does it take to have a commit replicated to a secondary node?
+
+All replication operations are asynchronous and are queued to be dispatched in
+a batched request every 10 minutes. Besides that, it depends on a lot of other
+factors including the amount of traffic, how big your commit is, the
+connectivity between your nodes, your hardware, etc.
+
+## What if the SSH server runs at a different port?
+
+We send the clone url from the primary server to any secondaries, so it
+doesn't matter. If primary is running on port `2200`, clone url will reflect
+that.
+
+## Is this possible to set up a Docker Registry for a secondary node that mirrors the one on a primary node?
+
+Yes. See [Docker Registry for a secondary Geo node](docker_registry.md).

doc/administration/geo/replication/high_availability.md

+# Geo High Availability
+
+This document describes a minimal reference architecture for running Geo
+in a high availability configuration. If your HA setup differs from the one
+described, it is possible to adapt these instructions to your needs.
+
+## Architecture overview
+
+![Geo HA Diagram](../../img/high_availability/geo-ha-diagram.png)
+
+_[diagram source - gitlab employees only](https://docs.google.com/drawings/d/1z0VlizKiLNXVVVaERFwgsIOuEgjcUqDTWPdQYsE7Z4c/edit)_
+
+The topology above assumes that the primary and secondary Geo clusters
+are located in two separate locations, on their own virtual network
+with private IP addresses. The network is configured such that all machines within
+one geographic location can communicate with each other using their private IP addresses.
+The IP addresses given are examples and may be different depending on the
+network topology of your deployment.
+
+The only external way to access the two Geo deployments is by HTTPS at
+`gitlab.us.example.com` and `gitlab.eu.example.com` in the example above.
+
+> **Note:** The primary and secondary Geo deployments must be able to
+> communicate to each other over HTTPS.
+
+## Redis and PostgreSQL High Availability
+
+The primary and secondary Redis and PostgreSQL should be configured
+for high availability.  Because of the additional complexity involved
+in setting up this configuration for PostgreSQL and Redis
+it is not covered by this Geo HA documentation.
+The two services will instead be configured such that
+they will each run on a single machine.
+
+For more information about setting up a highly available PostgreSQL cluster and Redis cluster using the omnibus package see the high availability documentation for
+[PostgreSQL](../../high_availability/database.md) and
+[Redis](../../high_availability/redis.md), respectively.
+
+From these instructions you will need the following for the examples below:
+* `gitlab_rails['db_password']` for the PostgreSQL "DB password"
+* `redis['password']` for the Redis "Redis password"
+
+NOTE: **Note:**
+It is possible to use cloud hosted services for PostgreSQL and Redis but this is beyond the scope of this document.
+
+### Prerequisites
+
+Make sure you have GitLab EE installed using the
+[Omnibus package](https://about.gitlab.com/installation).
+
+
+### Step 1: Configure the Geo Backend Services
+
+On the **primary** backend servers configure the following services:
+
+* [Redis](../../high_availability/redis.md) for high availability.
+* [NFS Server](../../high_availability/nfs.md) for repository, LFS, and upload storage.
+* [PostgreSQL](../../high_availability/database.md) for high availability.
+
+On the **secondary** backend servers configure the following services:
+
+* [Redis](../../high_availability/redis.md) for high availability.
+* [NFS Server](../../high_availability/nfs.md) which will store data that is synchronized from the Geo primary.
+
+### Step 2: Configure the Postgres services on the Geo Secondary
+
+1. Configure the [secondary Geo PostgreSQL database](database.md)
+ as a read-only secondary of the primary Geo PostgreSQL database.
+
+1. Configure the Geo tracking database on the secondary server, to do this modify `/etc/gitlab/gitlab.rb`:
+
+    ```ruby
+    geo_postgresql['enable'] = true
+
+    geo_postgresql['listen_address'] = '10.1.4.1'
+    geo_postgresql['trust_auth_cidr_addresses'] = ['10.1.0.0/16']
+
+    geo_secondary['auto_migrate'] = true
+    geo_secondary['db_host'] = '10.1.4.1'
+    geo_secondary['db_password'] = 'Geo tracking DB password'
+    ```
+
+NOTE: **Note:**
+Be sure that other non-postgresql services are disabled by setting `enable` to `false` in
+the [gitlab.rb configuration](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template).
+
+After making these changes be sure to run `sudo gitlab-ctl reconfigure` so that they take effect.
+
+### Step 3: Setup the LoadBalancer
+
+In this topology there will need to be a load balancers at each geographical location
+to route traffic to the application servers.
+
+See the [Load Balancer for GitLab HA](../../high_availability/load_balancer.md)
+documentation for more information.
+
+### Step 4: Configure the Geo Frontend Application Servers
+
+In the architecture overview there are two machines running the GitLab application
+services.  These services are enabled selectively in the configuration. Additionally
+the addresses of the remote endpoints for PostgreSQL and Redis will need to be specified.
+
+#### On the GitLab Primary Frontend servers
+
+1. Edit `/etc/gitlab/gitlab.rb` and ensure the following to disable PostgreSQL and Redis from running locally.
+
+    ```ruby
+    ##
+    ## Disable PostgreSQL on the local machine and connect to the remote
+    ##
+
+    postgresql['enable'] = false
+    gitlab_rails['auto_migrate'] = false
+    gitlab_rails['db_host'] = '10.0.3.1'
+    gitlab_rails['db_password'] = 'DB password'
+
+    ##
+    ## Disable Redis on the local machine and connect to the remote
+    ##
+
+    redis['enable'] = false
+    gitlab_rails['redis_host'] = '10.0.2.1'
+    gitlab_rails['redis_password'] = 'Redis password'
+
+    geo_primary_role['enable'] = true
+    ```
+
+#### On the GitLab Secondary Frontend servers
+
+On the secondary the remote endpoint for the PostgreSQL Geo database will
+be specified.
+
+1. Edit `/etc/gitlab/gitlab.rb` and ensure the following to disable PostgreSQL and Redis from running locally. Configure the secondary to connect to the Geo tracking database.
+
+
+    ```ruby
+    ##
+    ## Disable PostgreSQL on the local machine and connect to the remote
+    ##
+
+    postgresql['enable'] = false
+    gitlab_rails['auto_migrate'] = false
+    gitlab_rails['db_host'] = '10.1.3.1'
+    gitlab_rails['db_password'] = 'DB password'
+
+    ##
+    ## Disable Redis on the local machine and connect to the remote
+    ##
+
+    redis['enable'] = false
+    gitlab_rails['redis_host'] = '10.1.2.1'
+    gitlab_rails['redis_password'] = 'Redis password'
+
+
+    ##
+    ## Enable the geo secondary role and configure the
+    ## geo tracking database
+    ##
+
+    geo_secondary_role['enable'] = true
+    geo_secondary['db_host'] = '10.1.4.1'
+    geo_secondary['db_password'] = 'Geo tracking DB password'
+    geo_postgresql['enable'] = false
+    ```
+
+
+After making these changes [Reconfigure GitLab][] so that they take effect.
+
+On the primary the following GitLab frontend services will be enabled:
+
+* gitlab-pages
+* gitlab-workhorse
+* logrotate
+* nginx
+* registry
+* remote-syslog
+* sidekiq
+* unicorn
+
+On the secondary the following GitLab frontend services will be enabled:
+
+* geo-logcursor
+* gitlab-pages
+* gitlab-workhorse
+* logrotate
+* nginx
+* registry
+* remote-syslog
+* sidekiq
+* unicorn
+
+Verify these services by running `sudo gitlab-ctl status` on the frontend
+application servers.
+
+[reconfigure GitLab]: ../../restart_gitlab.md#omnibus-gitlab-reconfigure
+[restart GitLab]: ../../restart_gitlab.md#omnibus-gitlab-restart

doc/administration/geo/replication/object_storage.md

+# Geo with Object storage
+
+Geo can be used in combination with Object Storage (AWS S3, or
+other compatible object storage).
+
+## Configuration
+
+At this time it is required that if object storage is enabled on the
+primary, it must also be enabled on the secondary.
+
+The secondary nodes can use the same storage bucket as the primary, or
+they can use a replicated storage bucket. At this time GitLab does not
+take care of content replication in object storage.
+
+For LFS, follow the documentation to
+[set up LFS object storage](../../../workflow/lfs/lfs_administration.md#setting-up-s3-compatible-object-storage).
+
+For CI job artifacts, there is similar documentation to configure
+[jobs artifact object storage](../../job_artifacts.md#using-object-storage)
+
+Complete these steps on all nodes, primary **and** secondary.
+
+## Replication
+
+When using Amazon S3, you can use
+[CRR](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) to
+have automatic replication between the bucket used by the primary and
+the bucket used by the secondary.
+
+If you are using Google Cloud Storage, consider using
+[Multi-Regional Storage](https://cloud.google.com/storage/docs/storage-classes#multi-regional).
+Or you can use the [Storage Transfer Service](https://cloud.google.com/storage/transfer/),
+although this only supports daily synchronization.
+
+For manual synchronization, or scheduled by `cron`, please have a look at:
+
+- [`s3cmd sync`](http://s3tools.org/s3cmd-sync)
+- [`gsutil rsync`](https://cloud.google.com/storage/docs/gsutil/commands/rsync)

doc/administration/geo/replication/troubleshooting.md

+# Geo Troubleshooting
+
+>**Note:**
+This list is an attempt to document all the moving parts that can go wrong.
+We are working into getting all this steps verified automatically in a
+rake task in the future.
+
+Setting up Geo requires careful attention to details and sometimes it's easy to
+miss a step. Here is a list of questions you should ask to try to detect
+what you need to fix (all commands and path locations are for Omnibus installs):
+
+#### First check the health of the secondary
+
+Visit the primary node's **Admin Area ➔ Geo Nodes** (`/admin/geo_nodes`) in
+your browser. We perform the following health checks on each secondary node
+to help identify if something is wrong:
+
+- Is the node running?
+- Is the node's secondary database configured for streaming replication?
+- Is the node's secondary tracking database configured?
+- Is the node's secondary tracking database connected?
+- Is the node's secondary tracking database up-to-date?
+
+![Geo health check](img/geo_node_healthcheck.png)
+
+There is also an option to check the status of the secondary node by running a special rake task:
+
+```
+sudo gitlab-rake geo:status
+```
+
+#### Is Postgres replication working?
+
+#### Are my nodes pointing to the correct database instance?
+
+You should make sure your primary Geo node points to the instance with
+writing permissions.
+
+Any secondary nodes should point only to read-only instances.
+
+#### Can Geo detect my current node correctly?
+
+Geo uses the defined node from the `Admin ➔ Geo` screen, and tries to match
+it with the value defined in the `/etc/gitlab/gitlab.rb` configuration file.
+The relevant line looks like: `external_url "http://gitlab.example.com"`.
+
+To check if the node on the current machine is correctly detected type:
+
+```bash
+sudo gitlab-rails runner "puts Gitlab::Geo.current_node.inspect"
+```
+
+and expect something like:
+
+```
+#<GeoNode id: 2, schema: "https", host: "gitlab.example.com", port: 443, relative_url_root: "", primary: false, ...>
+```
+
+By running the command above, `primary` should be `true` when executed in
+the primary node, and `false` on any secondary.
+
+#### How do I fix the message, "ERROR:  replication slots can only be used if max_replication_slots > 0"?
+
+This means that the `max_replication_slots` PostgreSQL variable needs to
+be set on the primary database. In GitLab 9.4, we have made this setting
+default to 1. You may need to increase this value if you have more Geo
+secondary nodes. Be sure to restart PostgreSQL for this to take
+effect. See the [PostgreSQL replication
+setup](database.md#postgresql-replication) guide for more details.
+
+#### How do I fix the message, "FATAL:  could not start WAL streaming: ERROR:  replication slot "geo_secondary_my_domain_com" does not exist"?
+
+This occurs when PostgreSQL does not have a replication slot for the
+secondary by that name. You may want to rerun the [replication
+process](database.md) on the secondary.
+
+#### How do I fix the message, "Command exceeded allowed execution time" when setting up replication?
+
+This may happen while [initiating the replication process](database.md#step-4-initiate-the-replication-process) on the Geo secondary, and indicates that your
+initial dataset is too large to be replicated in the default timeout (30 minutes).
+
+Re-run `gitlab-ctl replicate-geo-database`, but include a larger value for
+`--backup-timeout`:
+
+```bash
+sudo gitlab-ctl replicate-geo-database --host=primary.geo.example.com --slot-name=secondary_geo_example_com --backup-timeout=21600
+```
+
+This will give the initial replication up to six hours to complete, rather than
+the default thirty minutes. Adjust as required for your installation.
+
+#### How do I fix the message, "PANIC: could not write to file 'pg_xlog/xlogtemp.123': No space left on device"
+
+Determine if you have any unused replication slots in the primary database.  This can cause large amounts of log data to build up in `pg_xlog`.
+Removing the unused slots can reduce the amount of space used in the `pg_xlog`.
+
+1. Start a PostgreSQL console session:
+
+    ```bash
+    sudo gitlab-psql gitlabhq_production
+    ```
+
+    Note that using `gitlab-rails dbconsole` will not work, because managing replication slots requires superuser permissions.
+
+2. View your replication slots with
+
+     ```sql
+     SELECT * FROM pg_replication_slots;
+     ```
+
+Slots where `active` is `f` are not active.
+
+- When this slot should be active, because you have a secondary configured using that slot,
+log in to that secondary and check the PostgreSQL logs why the replication is not running.
+
+- If you are no longer using the slot (e.g. you no longer have Geo enabled), you can remove it with in the PostgreSQL console session:
+
+    ```sql
+    SELECT pg_drop_replication_slot('name_of_extra_slot');
+    ```
+
+#### Very large repositories never successfully synchronize on the secondary
+
+GitLab places a timeout on all repository clones, including project imports
+and Geo synchronization operations. If a fresh `git clone` of a repository
+on the primary takes more than a few minutes, you may be affected by this.
+To increase the timeout, add the following line to `/etc/gitlab/gitlab.rb`
+on the secondary:
+
+```ruby
+gitlab_rails['gitlab_shell_git_timeout'] = 10800
+```
+
+Then reconfigure GitLab:
+
+```bash
+sudo gitlab-ctl reconfigure
+```
+
+This will increase the timeout to three hours (10800 seconds). Choose a time
+long enough to accomodate a full clone of your largest repositories.

doc/administration/geo/replication/tuning.md

+# Tuning Geo
+
+## Changing the sync capacity values
+
+In the Geo admin page (`/admin/geo_nodes`), there are several variables that
+can be tuned to improve performance of Geo:
+
+* Repository sync capacity
+* File sync capacity
+
+Increasing these values will increase the number of jobs that are scheduled,
+but this may not lead to a more downloads in parallel unless the number of
+available Sidekiq threads is also increased. For example, if repository sync
+capacity is increased from 25 to 50, you may also want to increase the number
+of Sidekiq threads from 25 to 50. See the [Sidekiq concurrency
+documentation](../../operations/extra_sidekiq_processes.html#concurrency)
+for more details.

doc/administration/geo/replication/using_a_geo_server.md

+[//]: # (Please update EE::GitLab::GeoGitAccess::GEO_SERVER_DOCS_URL if this file is moved)
+
+# Using a Geo Server
+
+After you set up the [database replication and configure the Geo nodes][req],
+there are a few things to consider:
+
+1. Users need an extra step to be able to fetch code from the secondary and push
+   to primary:
+
+     1. Clone the repository as you would normally do, but from the secondary node:
+
+         ```bash
+         git clone git@secondary.gitlab.example.com:user/repo.git
+         ```
+
+     1. Change the remote push URL to always push to primary, following this example:
+
+         ```bash
+         git remote set-url --push origin git@primary.gitlab.example.com:user/repo.git
+         ```
+
+[req]: index.md#setup-instructions

doc/administration/index.md

@@ -20,7 +20,8 @@ Learn how to install, configure, update, and maintain your GitLab instance.
   - **(Starter/Premium)** [Omnibus support for log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-shipping-gitlab-enterprise-edition-only)
 - [High Availability](high_availability/README.md): Configure multiple servers for scaling or high availability.
   - [High Availability on AWS](../university/high-availability/aws/README.md): Set up GitLab HA on Amazon AWS.
-- **(Premium)** [GitLab Geo](../gitlab-geo/README.md): Replicate your GitLab instance to other geographical locations as a read-only fully operational version.
+- **(Premium)** [Geo](geo/replication/index.md): Replicate your GitLab instance to other geographical locations as a read-only fully operational version.
+- **(Premium)** [Disaster Recovery](geo/disaster_recovery/index.md): Quickly fail-over to a different site with minimal effort in a disaster situation.
 - **(Premium)** [Pivotal Tile](../install/pivotal/index.md): Deploy GitLab as a pre-configured appliance using Ops Manager (BOSH) for Pivotal Cloud Foundry.
 
 ### Configuring GitLab

doc/administration/operations/fast_ssh_key_lookup.md

@@ -25,14 +25,14 @@ instructions will break installations using older versions of OpenSSH, such as
 those included with CentOS 6 as of September 2017. If you want to use this
 feature for CentOS 6, follow [the instructions on how to build and install a custom OpenSSH package](#compiling-a-custom-version-of-openssh-for-centos-6) before continuing.
 
-## Fast lookup is required for GitLab Geo
+## Fast lookup is required for Geo
 
 By default, GitLab manages an `authorized_keys` file, which contains all the
 public SSH keys for users allowed to access GitLab. However, to maintain a
 single source of truth, [Geo](../../gitlab-geo/README.md) needs to be configured to perform SSH fingerprint
 lookups via database lookup.
 
-As part of [setting up GitLab Geo](../../gitlab-geo/README.md#setup-instructions),
+As part of [setting up Geo](../../gitlab-geo/README.md#setup-instructions),
 you will be required to follow the steps outlined below for both the primary and
 secondary nodes, but note that the `Write to "authorized keys" file` checkbox
 only needs to be unchecked on the primary node since it will be reflected

doc/administration/repository_storage_types.md

@@ -29,7 +29,7 @@ Any change in the URL will need to be reflected on disk (when groups / users or
 projects are renamed). This can add a lot of load in big installations,
 especially if using any type of network based filesystem.
 
-For GitLab Geo in particular: Geo does work with legacy storage, but in some
+For Geo in particular: Geo does work with legacy storage, but in some
 edge cases due to race conditions it can lead to errors when a project is
 renamed multiple times in short succession, or a project is deleted and
 recreated under the same name very quickly. We expect these race events to be

doc/api/README.md

@@ -48,6 +48,7 @@ following locations:
 - [Pipeline Schedules](pipeline_schedules.md)
 - [Projects](projects.md) including setting Webhooks
 - [Project Access Requests](access_requests.md)
+- [Project import/export](project_import_export.md)
 - [Project Members](members.md)
 - [Project Snippets](project_snippets.md)
 - [Protected Branches](protected_branches.md)

doc/api/project_import_export.md

+# Project import API
+
+[Introduced][ce-41899] in GitLab 10.6
+
+[See also the project import/export documentation](../user/project/settings/import_export.md)
+
+## Import a file
+
+```http
+POST /projects/import
+```
+
+| Attribute | Type           | Required | Description                              |
+| --------- | -------------- | -------- | ---------------------------------------- |
+| `namespace` | integer/string | no | The ID or path of the namespace that the project will be imported to. Defaults to the current user's namespace |
+| `file` | string | yes | The file to be uploaded |
+| `path` | string | yes | Name and path for new project |
+
+To upload a file from your filesystem, use the `--form` argument. This causes
+cURL to post data using the header `Content-Type: multipart/form-data`.
+The `file=` parameter must point to a file on your filesystem and be preceded
+by `@`. For example:
+
+```console
+curl --request POST --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" --form "path=api-project" --form "file=@/path/to/file" https://gitlab.example.com/api/v4/projects/import
+```
+
+```json
+{
+  "id": 1,
+  "description": null,
+  "name": "api-project",
+  "name_with_namespace": "Administrator / api-project",
+  "path": "api-project",
+  "path_with_namespace": "root/api-project",
+  "created_at": "2018-02-13T09:05:58.023Z",
+  "import_status": "scheduled"
+}
+```
+
+## Import status
+
+Get the status of an import.
+
+```http
+GET /projects/:id/import
+```
+
+| Attribute | Type           | Required | Description                              |
+| --------- | -------------- | -------- | ---------------------------------------- |
+| `id`      | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
+
+```console
+curl --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" https://gitlab.example.com/api/v4/projects/1/import
+```
+
+Status can be one of `none`, `scheduled`, `failed`, `started`, or `finished`.
+
+If the status is `failed`, it will include the import error message under `import_error`.
+
+```json
+{
+  "id": 1,
+  "description": "Itaque perspiciatis minima aspernatur corporis consequatur.",
+  "name": "Gitlab Test",
+  "name_with_namespace": "Gitlab Org / Gitlab Test",
+  "path": "gitlab-test",
+  "path_with_namespace": "gitlab-org/gitlab-test",
+  "created_at": "2017-08-29T04:36:44.383Z",
+  "import_status": "started"
+}
+```
+
+[ce-41899]: https://gitlab.com/gitlab-org/gitlab-ce/issues/41899

doc/api/projects.md

@@ -1428,6 +1428,10 @@ DELETE /projects/:id/push_rule
 
 Read more in the [Branches](branches.md) documentation.
 
+## Project Import/Export
+
+Read more in the [Project import/export](project_import_export.md) documentation.
+
 ## Project members
 
 Read more in the [Project members](members.md) documentation.