Commit 1d44198d authored by GitLab Bot's avatar GitLab Bot

Merge remote-tracking branch 'upstream/master' into ce-to-ee-2018-05-16

parents 0d7352c2 4790e726
---
title: Refs containting sha checks are done by Gitaly
merge_request:
author:
type: other
......@@ -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.
......@@ -175,7 +175,7 @@ Remember that actions only describe that something happened, they don't describe
state.isLoading = false;
},
[types.REQUEST_ADD_USER](state, user) {
state.isAddingUser = true;
state.isAddingUser = true;
},
[types.RECEIVE_ADD_USER_SUCCESS](state, user) {
state.isAddingUser = false;
......@@ -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
......
......@@ -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"
# 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.
......@@ -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).
......@@ -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
......
......@@ -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
gitaly_ref_client.branch_names_contains_sha(sha)
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
gitaly_ref_client.tag_names_contains_sha(sha)
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
......
......@@ -615,32 +615,22 @@ 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-é' }
let(:head_id) { repository.rugged.head.target.oid }
let(:new_branch) { head_id }
let(:utf8_branch) { 'branch-é' }
before do
repository.create_branch(new_branch, 'master')
repository.create_branch(utf8_branch, 'master')
end
after do
repository.delete_branch(new_branch)
repository.delete_branch(utf8_branch)
end
it 'displays that branch' do
expect(repository.branch_names_contains_sha(head_id)).to include('master', new_branch, utf8_branch)
end
before do
repository.create_branch(new_branch, 'master')
repository.create_branch(utf8_branch, 'master')
end
context 'when Gitaly is enabled' do
it_behaves_like 'returning the right branches'
after do
repository.delete_branch(new_branch)
repository.delete_branch(utf8_branch)
end
context 'when Gitaly is disabled', :disable_gitaly do
it_behaves_like 'returning the right branches'
it 'displays that branch' do
expect(repository.branch_names_contains_sha(head_id)).to include('master', new_branch, utf8_branch)
end
end
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment