Merge branch 'ce-to-ee-2018-05-16' into 'master'

CE upstream - 2018-05-16 09:25 UTC

Closes gitaly#884

See merge request gitlab-org/gitlab-ee!5728

changelogs/unreleased/zj-ref-contains-sha-mandatory.yml

+---
+title: Refs containting sha checks are done by Gitaly
+merge_request:
+author:
+type: other

doc/development/fe_guide/vuex.md

@@ -68,10 +68,10 @@ Often we need to provide data from haml to our Vue application. Let's store it i
 You can use `mapState` to access state properties in the components.
 
 ### `actions.js`
-An action is a playload of information to send data from our application to our store.
+An action is a payload of information to send data from our application to our store.
 
 An action is usually composed by a `type` and a `payload` and they describe what happened.
-Enforcing that every change is described as an action lets us have a clear understanting of what is going on in the app.
+Enforcing that every change is described as an action lets us have a clear understanding of what is going on in the app.
 
 In this file, we will write the actions that will call the respective mutations:
 
@@ -87,7 +87,7 @@ In this file, we will write the actions that will call the respective mutations:
   export const fetchUsers = ({ state, dispatch }) => {
     dispatch('requestUsers');
 
-    axios.get(state.endoint)
+    axios.get(state.endpoint)
       .then(({ data }) => dispatch('receiveUsersSuccess', data))
       .catch((error) => {
         dispatch('receiveUsersError', error)
@@ -102,7 +102,7 @@ In this file, we will write the actions that will call the respective mutations:
   export const addUser = ({ state, dispatch }, user) => {
     dispatch('requestAddUser');
 
-    axios.post(state.endoint, user)
+    axios.post(state.endpoint, user)
       .then(({ data }) => dispatch('receiveAddUserSuccess', data))
       .catch((error) => dispatch('receiveAddUserError', error));
   }
@@ -126,7 +126,7 @@ The component MUST only dispatch the `fetchNamespace` action. Actions namespaced
 The `fetch` action will be responsible to dispatch `requestNamespace`, `receiveNamespaceSuccess` and `receiveNamespaceError`
 
 By following this pattern we guarantee:
-1. All aplications follow the same pattern, making it easier for anyone to maintain the code
+1. All applications follow the same pattern, making it easier for anyone to maintain the code
 1. All data in the application follows the same lifecycle pattern
 1. Actions are contained and human friendly
 1. Unit tests are easier
@@ -149,7 +149,7 @@ import { mapActions } from 'vuex';
 };
 ```
 
-#### `mutations.js`
+### `mutations.js`
 The mutations specify how the application state changes in response to actions sent to the store.
 The only way to change state in a Vuex store should be by committing a mutation.
 
@@ -183,12 +183,12 @@ Remember that actions only describe that something happened, they don't describe
     },
     [types.REQUEST_ADD_USER_ERROR](state, error) {
       state.isAddingUser = true;
-      state.errorAddingUser = error∂;
+      state.errorAddingUser = error;
     },
   };
 ```
 
-#### `getters.js`
+### `getters.js`
 Sometimes we may need to get derived state based on store state, like filtering for a specific prop.
 Using a getter will also cache the result based on dependencies due to [how computed props work](https://vuejs.org/v2/guide/computed.html#Computed-Caching-vs-Methods)
 This can be done through the `getters`:
@@ -213,7 +213,7 @@ import { mapGetters } from 'vuex';
 };
 ```
 
-#### `mutations_types.js`
+### `mutations_types.js`
 From [vuex mutations docs][vuex-mutations]:
 > It is a commonly seen pattern to use constants for mutation types in various Flux implementations. This allows the code to take advantage of tooling like linters, and putting all constants in a single file allows your collaborators to get an at-a-glance view of what mutations are possible in the entire application.
 
@@ -289,7 +289,7 @@ export default {
 ```
 
 ### Vuex Gotchas
-1. Do not call a mutation directly. Always use an action to commit a mutation. Doing so will keep consistency through out the application. From Vuex docs:
+1. Do not call a mutation directly. Always use an action to commit a mutation. Doing so will keep consistency throughout the application. From Vuex docs:
 
   >  why don't we just call store.commit('action') directly? Well, remember that mutations must be synchronous? Actions aren't. We can perform asynchronous operations inside an action.
 
@@ -342,7 +342,7 @@ describe('component', () => {
     };
 
     // populate the store
-    store.dipatch('addUser', user);
+    store.dispatch('addUser', user);
 
     vm = new Component({
       store,
@@ -352,6 +352,18 @@ describe('component', () => {
 });
 ```
 
+#### Testing Vuex actions and getters
+Because we're currently using [`babel-plugin-rewire`](https://github.com/speedskater/babel-plugin-rewire), you may encounter the following error when testing your Vuex actions and getters:
+`[vuex] actions should be function or object with "handler" function`
+
+To prevent this error from happening, you need to export an empty function as `default`:
+```
+// getters.js or actions.js
+
+// prevent babel-plugin-rewire from generating an invalid default during karma tests
+export default () => {};
+```
+
 [vuex-docs]: https://vuex.vuejs.org
 [vuex-structure]: https://vuex.vuejs.org/en/structure.html
 [vuex-mutations]: https://vuex.vuejs.org/en/mutations.html

doc/user/gitlab_com/index.md

@@ -75,7 +75,6 @@ Shared Runners on GitLab.com run in [autoscale mode] and powered by
 Google Cloud Platform and DigitalOcean. Autoscaling means reduced
 waiting times to spin up CI/CD jobs, and isolated VMs for each project,
 thus maximizing security.
-
 They're free to use for public open source projects and limited to 2000 CI
 minutes per month per group for private projects. Read about all
 [GitLab.com plans](https://about.gitlab.com/pricing/).
@@ -90,6 +89,10 @@ ephemeral instances with 3.75GB of RAM, CoreOS and the latest Docker Engine
 installed. Instances provide 1 vCPU and 25GB of HDD disk space. The default
 region of the VMs is US East1.
 
+Jobs handled by the shared Runners on GitLab.com (`shared-runners-manager-X.gitlab.com`),
+**will be timed out after 3 hours**, regardless of the timeout configured in a
+project. Check the issues [4010] and [4070] for the reference.
+
 Below are the shared Runners settings.
 
 | Setting                               | GitLab.com                                        | Default    |
@@ -340,3 +343,5 @@ High Performance TCP/HTTP Load Balancer:
 [mailgun]: https://www.mailgun.com/ "Mailgun website"
 [sidekiq]: http://sidekiq.org/ "Sidekiq website"
 [unicorn-worker-killer]: https://rubygems.org/gems/unicorn-worker-killer "unicorn-worker-killer"
+[4010]: https://gitlab.com/gitlab-com/infrastructure/issues/4010 "Find a good value for maximum timeout for Shared Runners"
+[4070]: https://gitlab.com/gitlab-com/infrastructure/issues/4070 "Configure per-runner timeout for shared-runners-manager-X on GitLab.com"

doc/user/project/bulk_editing.md

+# Bulk Editing
+
+>**Note:**
+- A permission level of `Reporter` or higher is required in order to manage
+issues.
+- A permission level of `Developer` or higher is required in order to manage
+merge requests.
+
+Fields across multiple issues or merge requests can be updated simutaneously by using the bulk edit feature.
+
+>**Note:**
+- Bulk editing of issues and merge requests is only available at the project level.
+
+To access the feature, navigate to either the issue or merge request list for the project and click 'Edit Issues' or 'Edit Merge Requests'. This will cause a sidebar to be shown on the right-hand side of the screen, where the available, editable fields are displayed. Checkboxes will also appear to the left-hand side of each issue or merge request, ready to be selected.
+
+Once all items have been selected, choose the appropriate fields and their values from the sidebar and click 'Update All' to apply these changes.
+

doc/user/project/issues/index.md

@@ -162,3 +162,7 @@ or Bugzilla.
 ### Issue's API
 
 Read through the [API documentation](../../../api/issues.md).
+
+### Bulk editing issues
+
+Find out about [bulk editing issues](../../project/bulk_editing.md).

doc/user/project/merge_requests/index.md

@@ -324,6 +324,10 @@ all your changes will be available to preview by anyone with the Review Apps lin
 
 [Read more about Review Apps.](../../../ci/review_apps/index.md)
 
+## Bulk editing merge requests
+
+Find out about [bulk editing merge requests](../../project/bulk_editing.md).
+
 ## Tips
 
 Here are some tips that will help you be more efficient with merge requests in

lib/gitlab/git/repository.rb

@@ -1471,25 +1471,11 @@ module Gitlab
       end
 
       def branch_names_contains_sha(sha)
-        gitaly_migrate(:branch_names_contains_sha,
-                      status: Gitlab::GitalyClient::MigrationStatus::OPT_OUT) do |is_enabled|
-          if is_enabled
         gitaly_ref_client.branch_names_contains_sha(sha)
-          else
-            refs_contains_sha('refs/heads/', sha)
-          end
-        end
       end
 
       def tag_names_contains_sha(sha)
-        gitaly_migrate(:tag_names_contains_sha,
-                       status: Gitlab::GitalyClient::MigrationStatus::OPT_OUT) do |is_enabled|
-          if is_enabled
         gitaly_ref_client.tag_names_contains_sha(sha)
-          else
-            refs_contains_sha('refs/tags/', sha)
-          end
-        end
       end
 
       def search_files_by_content(query, ref)
@@ -1634,27 +1620,6 @@ module Gitlab
         end
       end
 
-      def refs_contains_sha(refs_prefix, sha)
-        refs_prefix << "/" unless refs_prefix.ends_with?('/')
-
-        # By forcing the output to %(refname) each line wiht a ref will start with
-        # the ref prefix. All other lines can be discarded.
-        args = %W(for-each-ref --contains=#{sha} --format=%(refname) #{refs_prefix})
-        names, code = run_git(args)
-
-        return [] unless code.zero?
-
-        refs = []
-        left_slice_count = refs_prefix.length
-        names.lines.each do |line|
-          next unless line.start_with?(refs_prefix)
-
-          refs << encode_utf8(line.rstrip[left_slice_count..-1])
-        end
-
-        refs
-      end
-
       def rugged_write_config(full_path:)
         rugged.config['gitlab.fullpath'] = full_path
       end

spec/lib/gitlab/git/repository_spec.rb

@@ -615,7 +615,6 @@ describe Gitlab::Git::Repository, seed_helper: true do
   end
 
   describe '#branch_names_contains_sha' do
-    shared_examples 'returning the right branches' do
     let(:head_id) { repository.rugged.head.target.oid }
     let(:new_branch) { head_id }
     let(:utf8_branch) { 'branch-é' }
@@ -635,15 +634,6 @@ describe Gitlab::Git::Repository, seed_helper: true do
     end
   end
 
-    context 'when Gitaly is enabled' do
-      it_behaves_like 'returning the right branches'
-    end
-
-    context 'when Gitaly is disabled', :disable_gitaly do
-      it_behaves_like 'returning the right branches'
-    end
-  end
-
   describe "#refs_hash" do
     subject { repository.refs_hash }