Merge remote-tracking branch 'upstream/master' into qa-allow-setting-sandbox-group

* upstream/master: (27 commits)
  Set initial password for instance in LDAP QA test
  Backport EE changes to some hashed storage documentation to CE
  Remove allow_n_plus_1 from Git::Repository#branches_filter
  Bumps Gitlab Shell version to 6.0.3
  Make resetting column information overridable in EE
  Added 'clear' button to ci lint editor
  Issues and merge requests in subgroups docs
  Update docs labels CE
  Refactored merge_requests/show path in dispatcher.js
  wording
  don't check against a hardcoded user name
  10.5 Update the dependencies license list
  10.5 Update the .gitignore, .gitlab-ci.yml, and Dockerfile templates
  Create update guide for 10.5
  Update 10.5 source install guide
  Add docs for MR link in commit page
  Add groups to OpenID Connect claims
  Replaced $.get with axois.get
  Memoize MergeRequest#rebase_in_progress? to prevent N+1 queries in Gitaly
  [docs] Info rescheduling background migrations
  ...

doc/user/project/issues/index.md

@@ -64,9 +64,7 @@ You can also [search and filter](../../search/index.md#issues-and-merge-requests
 ### Issues per group
-View all the issues in a group (that is, all the issues across all projects in that
-group) by navigating to **Group > Issues**. This view also has the open and closed
-issue tabs.
+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)

doc/user/project/labels.md

 # Labels
-Labels provide an easy way to categorize the issues or merge requests based on
-descriptive titles like `bug`, `documentation` or any other text you feel like.
-They can have different colors, a description, and are visible throughout
-the issue tracker or inside each issue individually.
-With labels, you can navigate the issue tracker and filter any bloated
-information to visualize only the issues you are interested in. Let's see how
-that works.
-## Create new labels
+## Overview
+Labels allow you to categorize issues or merge requests using descriptive titles like `bug`, `feature request`, or `docs`. Each label also has a customizable color. They allow you to quickly and dynamically filter and manage issues or merge requests you care about, and are visible throughout GitLab in most places where issues and merge requests are located.
+## Project labels and group labels
+
+In GitLab, you can create project and group labels:
+
+- **Project labels** can be assigned to issues or merge requests in that project only. 
+- **Group labels** can be assigned to any issue or merge request of any project in that group. 
+- In the [future](https://gitlab.com/gitlab-org/gitlab-ce/issues/40915), you will be able to assign group labels to issues and merge reqeusts of projects in [subgroups](../group/subgroups/index.md).
+
+## Creating labels
 >**Note:**
-A permission level of `Developer` or higher is required in order to manage
-labels.
-Head over a single project and navigate to **Issues > Labels**.
-The first time you visit this page, you'll notice that there are no labels
-created yet.
-Creating a new label from scratch is as easy as pressing the **New label**
-button. From there on you can choose the name, give it an optional description,
-a color and you are set.
-When you are ready press the **Create label** button to create the new label.
-![New label](img/labels_new_label.png)
----
-## Default labels
-The very first time you visit the labels area, it's gonna be empty. In that
-case, it's possible to populate the labels for your project from a set of
-predefined labels.
-Click the link to 'Generate a default set of labels' and GitLab will
-generate them for you. There are 8 default generated labels in total:
-- bug
-- confirmed
-- critical
-- discussion
-- documentation
-- enhancement
-- suggestion
-- support
-## Labels Overview
-![Default generated labels](img/labels_default.png)
-You can see that from the labels page you can have an overview of the number of
-issues and merge requests assigned to each label.
-## Prioritize labels
->**Notes:**
->
-> - Introduced in GitLab 8.9.
-> - Priority sorting is based on the highest priority label only. This might
->   change in the future, follow the discussion in
->   https://gitlab.com/gitlab-org/gitlab-ce/issues/18554.
-Prioritized labels are like any other label, but sorted by priority. This allows
-you to sort issues and merge requests by label priority.
-To prioritize labels, navigate to your project's **Issues > Labels** and click
-on the star icon next to them to put them in the priority list. Click on the
-star icon again to remove them from the list.
-From there, you can drag them around to set the desired priority. Priority is
-set from high to low with an ascending order. Labels with no priority, count as
-having their priority set to null.
-![Prioritize labels](img/labels_prioritize.png)
-Now that you have labels prioritized, you can use the 'Label priority' and 'Priority' 
-sort orders in the issues or merge requests tracker.
-In the following, everything applies to both issues and merge requests, but we'll
-refer to just issues for brevity.
-The 'Label priority' sort order positions issues with higher priority labels
-toward the top, and issues with lower priority labels toward the bottom. A non-prioritized
-label is considered to have the lowest priority. For a given issue, we _only_ consider the
-highest priority label assigned to it in the comparison. ([We are discussing](https://gitlab.com/gitlab-org/gitlab-ce/issues/18554) 
-including all the labels in a given issue for this comparison.) Given two issues
-are equal according to this sort comparison, their relative order is equal, and 
-therefore it's not guaranteed that one will be always above the other.
-![Label priority sort order](img/label_priority_sort_order.png)
-The 'Priority' sort order comparison first considers an issue's milestone's due date,
-(if the issue is assigned a milestone and the milestone's due date exists), and then 
-secondarily considers the label priority comparison above. Sooner due dates results
-a higher sort order. If an issue doesn't have a milestone due date, it is equivalent to
-being assigned to a milestone that has a due date in the infinite future. Given two issues
-are equal according to this two-stage sort comparison, their relative order is equal, and 
-therefore it's not guaranteed that one will be always above the other.
-![Priority sort order](img/priority_sort_order.png)
-## Subscribe to labels
-If you don’t want to miss issues or merge requests that are important to you,
-simply subscribe to a label. You’ll get notified whenever the label gets added
-to an issue or merge request, making sure you don’t miss a thing.
-Go to your project's **Issues > Labels** area, find the label(s) you want to
-subscribe to and click on the eye icon. Click again to unsubscribe.
-![Subscribe to labels](img/labels_subscribe.png)
-If you work on a large or popular project, try subscribing only to the labels
-that are relevant to you. You’ll notice it’ll be much easier to focus on what’s
-important.
-## Create a new label when inside an issue
-There are times when you are already inside an issue searching to assign a
-label, only to realize it doesn't exist. Instead of going to the **Labels**
-page and being distracted from your original purpose, you can create new
-labels on the fly.
-Expand the issue sidebar and select **Create new label** from the labels dropdown
-list. Provide a name, pick a color and hit **Create**. The new label will be
-ready to used right away!
-![New label on the fly](img/labels_new_label_on_the_fly.png)
-## Assigning labels to issues and merge requests
-There are generally two ways to assign a label to an issue or merge request.
-The first one is to assign a label when you first create or edit an issue or
-merge request.
-The second way is by using the right sidebar when inside an issue or merge
-request. Expand it and hit **Edit** in the labels area. Start typing the name
-of the label you are looking for to narrow down the list, and select it. You
-can add more than one labels at once. When done, click outside the sidebar area
-for the changes to take effect.
-![Assign label in sidebar](img/labels_assign_label_sidebar.png)
-![Save labels in sidebar](img/labels_assign_label_sidebar_saved.png)
----
-To remove labels, expand the left sidebar and unmark them from the labels list.
-Simple as that.
-##  Use labels to filter issues
-Once you start adding labels to your issues, you'll see the benefit of it.
-Labels can have several uses, one of them being the quick filtering of issues
-or merge requests.
-Pick an existing label from the dropdown _Label_ menu or click on an existing
-label from the issue tracker. In the latter case, you also get to see the
-label description like shown below.
-![Filter labels](img/labels_filter.png)
----
-And if you added a description to your label, you can see it by hovering your
-mouse over the label in the issue tracker or wherever else the label is
-rendered.
-![Label tooltips](img/labels_description_tooltip.png)
+A permission level of `Developer` or higher is required in order to create labels.
+### New project label
+To create a **project label**, navigate to **Issues > Labels** in the project.
+Click the **New label** button. Enter the title, an optional description, and the background color. Click **Create label** to create the label.
+If a project has no labels, you can generate a default set of project labels from its empty label list page:
+![Labels generate default](img/labels_generate_default.png)
+GitLab will add the following default labels to the  project:
+![Labels default](img/labels_default.png)
+### New group label
+To create a **group label**, follow similar steps from above to project labels. Navigate to **Issues > Labels** in the group and create it from there.
+Group labels appear in every label list page of the group's child projects.
+![Labels list](img/labels_list.png)
+### New project label from sidebar
+From the sidebar of an issue or a merge request, you can create a create a new **project label** inline immediately, instead of navigating to the project label list page.
+![Labels inline](img/new_label_from_sidebar.gif)
+## Editing labels
+NOTE: **Note:**
+A permission level of `Developer` or higher is required in order to edit labels.
+You can update a label by navigating to **Issues > Labels** in the project ot group and clicking the pencil icon.
+You can delete a label by clicking the trash icon.
+### Promoting project labels to group labels
+If you are expanding from a few projects to a larger number of projects within the same group, you may want to share the same label among multiple projects in the same group. If you previously created a project label and now want to make it available for other projects, you can promote it to a group label.
+From the project label list page, you can promote a project label to a group label. This will merge all project labels across all projects in this group with the same name into a single group label. All issues and merge requests that previously were assigned one of these project labels will now be assigned the new group label. This action cannot be reversed and the changes are permanent.
+![Labels promotion](img/labels_promotion.png)
+## Assigning labels from the sidebar
+Every issue and merge request can be assigned any number of labels. The labels are visible on every issue and merge request page, in the sidebar. They are also visible in the issue board. From the sidebar, you can assign or unassign a label to the object (i.e. label or unlabel it). You can also perform this as a [quick action](quick_actions.md) in a comment.
+| View labels in sidebar | Assign labels from sidebar |
+|:---:|:---:|
+| ![Labels sidebar](img/labels_sidebar.png) | ![Labels sidebar assign](img/labels_sidebar_assign.png) |
+## Filtering issues and merge requests by label
+### Filtering in list pages
+From the project issue list page and the project merge request list page, you can [filter](../search/index.md#issues-and-merge-requests) by both group labels and project labels.
+From the group issue list page and the group merge request list page, you can [filter](../search/index.md#issues-and-merge-requests) by both group labels and project labels.
+![Labels group issues](img/labels_group_issues.png)
+### Filtering in issue boards
+- From [project boards](issue_board.md), you can filter by both group labels and project labels in the [search and filter bar](../search/index.md#issue-boards).
+## Subscribing to labels
+From the project label list page and the group label list page, you can subscribe to [notifications](../../workflow/notifications.md) of a given label, to alert you that that label has been assigned to an issue or merge request.
+![Labels subscriptions](img/labels_subscriptions.png)
+## Label priority
+>**Notes:**
+>
+> - Introduced in GitLab 8.9.
+> - Priority sorting is based on the highest priority label only. [This discussion](https://gitlab.com/gitlab-org/gitlab-ce/issues/18554) considers changing this.
+Labels can have relative priorities, which are used in the "Label priority" and "Priority" sort orders of the issue and merge request list pages.
+From the project label list page, star a label to indicate that it has a priority. Drag starred labels up and down to change their priority. Higher means higher priority. Prioritization happens at the project level, only on the project label list page, and not on the group label list page. However, both project and group labels can be prioritized on the project label list page since both types are displayed on the project label list page.
+![Labels prioritized](img/labels_prioritized.png)
+On the project and group issue and merge request list pages, you can sort by `Label priority` and `Priority`, which account for objects (issues and merge requests) that have prioritized labels assigned to them.
+If you sort by `Label priority`, GitLab considers this sort comparison order:
+- Object with a higher priority prioritized label.
+- Object without a prioritized label.
+Ties are broken arbitrarily. (Note that we _only_ consider the highest prioritized label in an object, and not any of the lower prioritized labels. [This discussion](https://gitlab.com/gitlab-org/gitlab-ce/issues/18554) considers changing this.)
+![Labels sort label priority](img/labels_sort_label_priority.png)
+If you sort by `Priority`, GitLab considers this sort comparison order:
+- Object's assigned [milestone](milestones/index.md)'s due date is sooner, provided the object has a milestone and the milestone has a due date. If this isn't the case, consider the object having a due date in the infinite future.
+- Object with a higher priority prioritized label.
+- Object without a prioritized label.
+Ties are broken arbitrarily.
+![Labels sort priority](img/labels_sort_priority.png)

doc/user/project/merge_requests/index.md

@@ -70,9 +70,9 @@ and you can use the tabs available to quickly filter by open and closed. You can
 ## Merge requests per group
-View all the merge requests in a group (that is, all the merge requests across all projects in that
-group) by navigating to **Group > Merge Requests**. This view also has the open, merged, and closed
-merge request tabs, from which you can [search and filter the results](../../search/index.md#issues-and-merge-requests-per-group).
+View merge requests in all projects in the group, including all projects of all descendant subgroups of the group. Navigate to **Group > Merge Requests** to view these merge requests. This view also has the open and closed merge requests tabs.
+
+You can [search and filter the results](../../search/index.md#issues-and-merge-requests-per-group) from here.
 ![Group Issues list view](img/group_merge_requests_list_view.png)
@@ -146,6 +146,19 @@ administrator to do so.
 ![Create new merge requests by email](img/create_from_email.png)
+## Find the merge request that introduced a change
+
+> **Note**: this feature was [implemented in GitLab 10.5](https://gitlab.com/gitlab-org/gitlab-ce/issues/2383).
+
+When viewing the commit details page, GitLab will link to the merge request (or
+merge requests, if it's in more than one) containing that commit.
+
+This only applies to commits that are in the most recent version of a merge
+request - if a commit was in a merge request, then rebased out of that merge
+request, they will not be linked.
+
+[Read more about merge request versions](versions.md)
+
 ## Revert changes
 GitLab implements Git's powerful feature to revert any commit with introducing
@@ -160,7 +173,7 @@ of merge request diff is created. When you visit a merge request that contains
 more than one pushes, you can select and compare the versions of those merge
 request diffs.
-[Read more about the merge requests versions.](versions.md)
+[Read more about merge request versions](versions.md)
 ## Work In Progress merge requests

doc/user/project/merge_requests/work_in_progress_merge_requests.md

@@ -7,7 +7,8 @@ have been marked a **Work In Progress**.
 ![Blocked Accept Button](img/wip_blocked_accept_button.png)
 To mark a merge request a Work In Progress, simply start its title with `[WIP]`
-or `WIP:`.
+or `WIP:`. As an alternative, you're also able to do it by sending a commit 
+with its title starting with `wip` or `WIP` to the merge request's source branch.
 ![Mark as WIP](img/wip_mark_as_wip.png)

doc/user/project/pages/getting_started_part_three.md

@@ -155,15 +155,40 @@ Certificates are NOT required to add to your custom
 (sub)domain on your GitLab Pages project, though they are
 highly recommendable.
-The importance of having any website securely served under HTTPS
-is explained on the introductory section of the blog post
-[Secure GitLab Pages with StartSSL](https://about.gitlab.com/2016/06/24/secure-gitlab-pages-with-startssl/#https-a-quick-overview).
-The reason why certificates are so important is that they encrypt
+Let's start with an introduction to the importance of HTTPS.
+Alternatively, jump ahead to [adding certificates to your project](#adding-certificates-to-your-project).
+#### Why should I care about HTTPS?
+
+This might be your first question. If our sites are hosted by GitLab Pages,
+they are static, hence we are not dealing with server-side scripts
+nor credit card transactions, then why do we need secure connections?
+
+Back in the 1990s, where HTTPS came out, [SSL](https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0.2C_2.0_and_3.0) was considered a "special"
+security measure, necessary just for big companies, like banks and shoppings sites
+with financial transactions.
+Now we have a different picture. [According to Josh Aas](https://letsencrypt.org/2015/10/29/phishing-and-malware.html), Executive Director at [ISRG](https://en.wikipedia.org/wiki/Internet_Security_Research_Group):
+
+> _We’ve since come to realize that HTTPS is important for almost all websites. It’s important for any website that allows people to log in with a password, any website that [tracks its users](https://www.washingtonpost.com/news/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/) in any way, any website that [doesn’t want its content altered](http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/), and for any site that offers content people might not want others to know they are consuming. We’ve also learned that any site not secured by HTTPS [can be used to attack other sites](http://krebsonsecurity.com/2015/04/dont-be-fodder-for-chinas-great-cannon/)._
+
+Therefore, the reason why certificates are so important is that they encrypt
 the connection between the **client** (you, me, your visitors)
 and the **server** (where you site lives), through a keychain of
 authentications and validations.
+How about taking Josh's advice and protecting our sites too? We will be
+well supported, and we'll contribute to a safer internet.
+
+#### Organizations supporting HTTPS
+
+There is a huge movement in favor of securing all the web. W3C fully
+[supports the cause](https://w3ctag.github.io/web-https/) and explains very well
+the reasons for that. Richard Barnes, a writer for Mozilla Security Blog,
+suggested that [Firefox would deprecate HTTP](https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/),
+and would no longer accept unsecured connections. Recently, Mozilla published a
+[communication](https://blog.mozilla.org/security/2016/03/29/march-2016-ca-communication/)
+reiterating the importance of HTTPS.
+
 ### Issuing Certificates
 GitLab Pages accepts [PEM](https://support.quovadisglobal.com/kb/a37/what-is-pem-format.aspx) certificates issued by

doc/user/project/pages/index.md

@@ -54,7 +54,6 @@ _Blog posts for securing GitLab Pages custom domains with SSL/TLS certificates:_
 - [CloudFlare](https://about.gitlab.com/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/)
 - [Let's Encrypt](https://about.gitlab.com/2016/04/11/tutorial-securing-your-gitlab-pages-with-tls-and-letsencrypt/) (outdated)
-- [StartSSL](https://about.gitlab.com/2016/06/24/secure-gitlab-pages-with-startssl/) (deprecated)
 ## Advanced use

lib/api/internal.rb

@@ -13,7 +13,7 @@ module API
       #   key_id - ssh key id for Git over SSH
       #   user_id - user id for Git over HTTP
       #   protocol - Git access protocol being used, e.g. HTTP or SSH
-      #   project - project path with namespace
+      #   project - project full_path (not path on disk)
       #   action - git action (git-upload-pack or git-receive-pack)
       #   changes - changes as "oldrev newrev ref", see Gitlab::ChangesList
       post "/allowed" do

lib/gitlab/background_migration/create_fork_network_memberships_range.rb

@@ -14,6 +14,14 @@ module Gitlab
       def perform(start_id, end_id)
         log("Creating memberships for forks: #{start_id} - #{end_id}")
+        insert_members(start_id, end_id)
+
+        if missing_members?(start_id, end_id)
+          BackgroundMigrationWorker.perform_in(RESCHEDULE_DELAY, "CreateForkNetworkMembershipsRange", [start_id, end_id])
+        end
+      end
+
+      def insert_members(start_id, end_id)
         ActiveRecord::Base.connection.execute <<~INSERT_MEMBERS
           INSERT INTO fork_network_members (fork_network_id, project_id, forked_from_project_id)
@@ -33,10 +41,9 @@ module Gitlab
             WHERE existing_members.project_id = forked_project_links.forked_to_project_id
           )
         INSERT_MEMBERS
-
-        if missing_members?(start_id, end_id)
-          BackgroundMigrationWorker.perform_in(RESCHEDULE_DELAY, "CreateForkNetworkMembershipsRange", [start_id, end_id])
-        end
+      rescue ActiveRecord::RecordNotUnique => e
+        # `fork_network_member` was created concurrently in another migration
+        log(e.message)
       end
       def missing_members?(start_id, end_id)

lib/gitlab/git/repository.rb

@@ -1614,17 +1614,14 @@ module Gitlab
       # Gitaly note: JV: Trying to get rid of the 'filter' option so we can implement this with 'git'.
       def branches_filter(filter: nil, sort_by: nil)
-        # n+1: https://gitlab.com/gitlab-org/gitlab-ce/issues/37464
-        branches = Gitlab::GitalyClient.allow_n_plus_1_calls do
-          rugged.branches.each(filter).map do |rugged_ref|
-            begin
-              target_commit = Gitlab::Git::Commit.find(self, rugged_ref.target)
-              Gitlab::Git::Branch.new(self, rugged_ref.name, rugged_ref.target, target_commit)
-            rescue Rugged::ReferenceError
-              # Omit invalid branch
-            end
-          end.compact
-        end
+        branches = rugged.branches.each(filter).map do |rugged_ref|
+          begin
+            target_commit = Gitlab::Git::Commit.find(self, rugged_ref.target)
+            Gitlab::Git::Branch.new(self, rugged_ref.name, rugged_ref.target, target_commit)
+          rescue Rugged::ReferenceError
+            # Omit invalid branch
+          end
+        end.compact
         sort_branches(branches, sort_by)
       end

lib/gitlab/shell.rb

@@ -294,7 +294,8 @@ module Gitlab
     #   add_namespace("/path/to/storage", "gitlab")
     #
     def add_namespace(storage, name)
-      Gitlab::GitalyClient.migrate(:add_namespace) do |enabled|
+      Gitlab::GitalyClient.migrate(:add_namespace,
+                                   status: Gitlab::GitalyClient::MigrationStatus::OPT_OUT) do |enabled|
         if enabled
           gitaly_namespace_client(storage).add(name)
         else
@@ -315,7 +316,8 @@ module Gitlab
     #   rm_namespace("/path/to/storage", "gitlab")
     #
     def rm_namespace(storage, name)
-      Gitlab::GitalyClient.migrate(:remove_namespace) do |enabled|
+      Gitlab::GitalyClient.migrate(:remove_namespace,
+                               status: Gitlab::GitalyClient::MigrationStatus::OPT_OUT) do |enabled|
         if enabled
           gitaly_namespace_client(storage).remove(name)
         else
@@ -333,7 +335,8 @@ module Gitlab
     #   mv_namespace("/path/to/storage", "gitlab", "gitlabhq")
     #
     def mv_namespace(storage, old_name, new_name)
-      Gitlab::GitalyClient.migrate(:rename_namespace) do |enabled|
+      Gitlab::GitalyClient.migrate(:rename_namespace,
+                                   status: Gitlab::GitalyClient::MigrationStatus::OPT_OUT) do |enabled|
         if enabled
           gitaly_namespace_client(storage).rename(old_name, new_name)
         else
@@ -368,7 +371,8 @@ module Gitlab
     #
     # Gitaly migration: https://gitlab.com/gitlab-org/gitaly/issues/385
     def exists?(storage, dir_name)
-      Gitlab::GitalyClient.migrate(:namespace_exists) do |enabled|
+      Gitlab::GitalyClient.migrate(:namespace_exists,
+                                   status: Gitlab::GitalyClient::MigrationStatus::OPT_OUT) do |enabled|
         if enabled
           gitaly_namespace_client(storage).exists?(dir_name)
         else

qa/qa/page/main/login.rb

@@ -31,22 +31,29 @@ module QA
           end
         end
+        def set_initial_password_if_present
+          if page.has_content?('Change your password')
+            fill_in :user_password, with: Runtime::User.password
+            fill_in :user_password_confirmation, with: Runtime::User.password
+            click_button 'Change your password'
+          end
+        end
+
         def sign_in_using_ldap_credentials
-          click_link 'LDAP'
-          fill_in :username, with: Runtime::User.name
-          fill_in :password, with: Runtime::User.password
-          click_button 'Sign in'
+          using_wait_time 0 do
+            set_initial_password_if_present
+            click_link 'LDAP'
+            fill_in :username, with: Runtime::User.name
+            fill_in :password, with: Runtime::User.password
+            click_button 'Sign in'
+          end
         end
         def sign_in_using_credentials
           using_wait_time 0 do
-            if page.has_content?('Change your password')
-              fill_in :user_password, with: Runtime::User.password
-              fill_in :user_password_confirmation, with: Runtime::User.password
-              click_button 'Change your password'
-            end
+            set_initial_password_if_present
             click_link 'Standard' if page.has_content?('LDAP')

qa/qa/specs/features/api/users_spec.rb

@@ -14,7 +14,7 @@ module QA
       end
       scenario 'submit request with a valid user name' do
-        get request.url, { params: { username: 'root' } }
+        get request.url, { params: { username: Runtime::User.name } }
         expect_status(200)
         expect(json_body).to be_an Array
@@ -23,7 +23,7 @@ module QA
       end
       scenario 'submit request with an invalid user name' do
-        get request.url, { params: { username: 'invalid' } }
+        get request.url, { params: { username: SecureRandom.hex(10) } }
         expect_status(200)
         expect(json_body).to be_an Array

spec/controllers/profiles_controller_spec.rb

@@ -69,9 +69,8 @@ describe ProfilesController, :request_store do
   describe 'PUT update_username' do
     let(:namespace) { user.namespace }
-    let(:project) { create(:project_empty_repo, namespace: namespace) }
     let(:gitlab_shell) { Gitlab::Shell.new }
-    let(:new_username) { 'renamedtosomethingelse' }
+    let(:new_username) { generate(:username) }
     it 'allows username change' do
       sign_in(user)
@@ -85,16 +84,39 @@ describe ProfilesController, :request_store do
       expect(user.username).to eq(new_username)
     end
-    it 'moves dependent projects to new namespace' do
-      sign_in(user)
-      put :update_username,
-        user: { username: new_username }
-      user.reload
-      expect(response.status).to eq(302)
-      expect(gitlab_shell.exists?(project.repository_storage_path, "#{new_username}/#{project.path}.git")).to be_truthy
+    context 'with legacy storage' do
+      it 'moves dependent projects to new namespace' do
+        project = create(:project_empty_repo, :legacy_storage, namespace: namespace)
+        sign_in(user)
+        put :update_username,
+          user: { username: new_username }
+        user.reload
+
+        expect(response.status).to eq(302)
+        expect(gitlab_shell.exists?(project.repository_storage_path, "#{new_username}/#{project.path}.git")).to be_truthy
+      end
+    end
+
+    context 'with hashed storage' do
+      it 'keeps repository location unchanged on disk' do
+        project = create(:project_empty_repo, namespace: namespace)
+
+        before_disk_path = project.disk_path
+
+        sign_in(user)
+
+        put :update_username,
+          user: { username: new_username }
+
+        user.reload
+
+        expect(response.status).to eq(302)
+        expect(gitlab_shell.exists?(project.repository_storage_path, "#{project.disk_path}.git")).to be_truthy
+        expect(before_disk_path).to eq(project.disk_path)
+      end
     end
   end
 end

spec/controllers/projects_controller_spec.rb

@@ -288,62 +288,82 @@ describe ProjectsController do
     render_views
     let(:admin) { create(:admin) }
-    let(:project) { create(:project, :repository) }
     before do
       sign_in(admin)
     end
-    context 'when only renaming a project path' do
-      it "sets the repository to the right path after a rename" do
-        expect { update_project path: 'renamed_path' }
-          .to change { project.reload.path }
-        expect(project.path).to include 'renamed_path'
-        expect(assigns(:repository).path).to include project.path
-        expect(response).to have_gitlab_http_status(302)
-      end
-    end
-    context 'when project has container repositories with tags' do
-      before do
-        stub_container_registry_config(enabled: true)
-        stub_container_registry_tags(repository: /image/, tags: %w[rc1])
-        create(:container_repository, project: project, name: :image)
+    shared_examples_for 'updating a project' do
+      context 'when only renaming a project path' do
+        it "sets the repository to the right path after a rename" do
+          original_repository_path = project.repository.path
+          expect { update_project path: 'renamed_path' }
+            .to change { project.reload.path }
+          expect(project.path).to include 'renamed_path'
+          if project.hashed_storage?(:repository)
+            expect(assigns(:repository).path).to eq(original_repository_path)
+          else
+            expect(assigns(:repository).path).to include(project.path)
+          end
+
+          expect(response).to have_gitlab_http_status(302)
+        end
       end
-      it 'does not allow to rename the project' do
-        expect { update_project path: 'renamed_path' }
-          .not_to change { project.reload.path }
-        expect(controller).to set_flash[:alert].to(/container registry tags/)
-        expect(response).to have_gitlab_http_status(200)
+      context 'when project has container repositories with tags' do
+        before do
+          stub_container_registry_config(enabled: true)
+          stub_container_registry_tags(repository: /image/, tags: %w[rc1])
+          create(:container_repository, project: project, name: :image)
+        end
+        it 'does not allow to rename the project' do
+          expect { update_project path: 'renamed_path' }
+            .not_to change { project.reload.path }
+
+          expect(controller).to set_flash[:alert].to(/container registry tags/)
+          expect(response).to have_gitlab_http_status(200)
+        end
       end
-    end
-    it 'updates Fast Forward Merge attributes' do
-      controller.instance_variable_set(:@project, project)
-      params = {
-        merge_method: :ff
-      }
-      put :update,
-          namespace_id: project.namespace,
-          id: project.id,
-          project: params
-      expect(response).to have_gitlab_http_status(302)
-      params.each do |param, value|
-        expect(project.public_send(param)).to eq(value)
+      it 'updates Fast Forward Merge attributes' do
+        controller.instance_variable_set(:@project, project)
+        params = {
+          merge_method: :ff
+        }
+        put :update,
+            namespace_id: project.namespace,
+            id: project.id,
+            project: params
+        expect(response).to have_gitlab_http_status(302)
+        params.each do |param, value|
+          expect(project.public_send(param)).to eq(value)
+        end
+      end
+
+      def update_project(**parameters)
+        put :update,
+            namespace_id: project.namespace.path,
+            id: project.path,
+            project: parameters
       end
     end
-    def update_project(**parameters)
-      put :update,
-          namespace_id: project.namespace.path,
-          id: project.path,
-          project: parameters
+    context 'hashed storage' do
+      let(:project) { create(:project, :repository) }
+
+      it_behaves_like 'updating a project'
+    end
+
+    context 'legacy storage' do
+      let(:project) { create(:project, :repository, :legacy_storage) }
+
+      it_behaves_like 'updating a project'
     end
   end