- 09 Dec, 2016 2 commits
-
-
Adam Niedzielski authored
The target branch of a merge request has to be a branch in the project for which the merge request is submitted. When a branch changes in a fork, it does not make sense to reload diffs of merge requests in the upstream project that use the same branch name as the target branch. Please note that it does make sense to reload diffs when the source branch changes.
-
Douwe Maan authored
Replace MR access checks with use of MergeRequestsFinder Split from !2024 to partially solve https://gitlab.com/gitlab-org/gitlab-ce/issues/23867
- Potentially untested - No test coverage - Test coverage of some sort exists (a test failed when error raised) - Test coverage of return value (a test failed when nil used) - Permissions check tested - [x] app/finders/notes_finder.rb:17 - [x] app/views/layouts/nav/_project.html.haml:80 [`.count`] - [x] app/controllers/concerns/creates_commit.rb:84 - [x] app/controllers/projects/commits_controller.rb:24 - [x] app/controllers/projects/compare_controller.rb:56 - [x] app/controllers/projects/discussions_controller.rb:29 - [x] app/controllers/projects/todos_controller.rb:27 - [x] app/models/commit.rb:268 - [x] lib/gitlab/search_results.rb:71 - [x] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#d1c10892daedb4d4dd3d4b12b6d071091eea83df_267_266 Memoize ` merged_merge_request(current_user)` - [x] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#d1c10892daedb4d4dd3d4b12b6d071091eea83df_248_247 Expected side effect for `merged_merge_request!`, consider `skip_authorization: true`. - [x] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#d1c10892daedb4d4dd3d4b12b6d071091eea83df_269_269 Scary use of unchecked `merged_merge_request?` See merge request !2033
-
- 05 Dec, 2016 1 commit
-
-
Bob Van Landuyt authored
When a merge request can only be merged when all discussions are resolved. This feature allows to easily delegate those discussions to a new issue, while marking them as resolved in the merge request. The user is presented with a new issue, prepared with mentions of all unresolved discussions, including the first unresolved note of the discussion, time and link to the note. When the issue is created, the discussions in the merge request will get a system note directing the user to the newly created issue.
-
- 02 Dec, 2016 1 commit
-
-
Oswaldo Ferreira authored
-
- 01 Dec, 2016 1 commit
-
-
Adam Niedzielski authored
when we care only about the number of commits We do not have to instantiate all objects in this case.
-
- 29 Nov, 2016 1 commit
-
-
Grzegorz Bizon authored
-
- 28 Nov, 2016 1 commit
-
-
Adam Niedzielski authored
-
- 23 Nov, 2016 2 commits
-
-
Yorick Peterse authored
Flushing the events cache worked by updating a recent number of rows in the "events" table. This has the result that on PostgreSQL a lot of dead tuples are produced on a regular basis. This in turn means that PostgreSQL will spend considerable amounts of time vacuuming this table. This in turn can lead to an increase of database load. For GitLab.com we measured the impact of not using events caching and found no measurable increase in response timings. Meanwhile not flushing the events cache lead to the "events" table having no more dead tuples as now rows are only inserted into this table. As a result of this we are hereby removing events caching as it does not appear to help and only increases database load. For more information see the following comment: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6578#note_18864037
-
Douwe Maan authored
-
- 21 Nov, 2016 1 commit
-
-
Rémy Coutable authored
Also allow merge request to be merged with skipped pipeline and the "only allow merge when pipeline is green" feature enabled Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 17 Nov, 2016 2 commits
-
-
James Lopez authored
-
James Lopez authored
add pipeline id to merge request metrics table. Also, updated the pipeline worker to populate this field.
-
- 09 Nov, 2016 1 commit
-
-
Grzegorz Bizon authored
-
- 04 Nov, 2016 1 commit
-
-
Rodolfo Santos authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 03 Nov, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 28 Oct, 2016 1 commit
-
-
Guilherme Salazar authored
fix issues pointed out in !6527 add task completion status feature to CHANGELOG
-
- 24 Oct, 2016 1 commit
-
-
David Wagner authored
They were Rails' default and are unnecessarily overridden. Signed-off-by: David Wagner <david@marvid.fr>
-
- 20 Oct, 2016 3 commits
-
-
Nick Thomas authored
-
Nick Thomas authored
-
Nick Thomas authored
This reverts commit 31c37c6c. See #23341
-
- 19 Oct, 2016 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 18 Oct, 2016 3 commits
-
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
- 14 Oct, 2016 5 commits
-
-
Z.J. van de Weg authored
-
Z.J. van de Weg authored
-
Z.J. van de Weg authored
- 13 Oct, 2016 1 commit
-
-
Sean McGivern authored
When reading conflicts: 1. Add a `type` field. `text` works as before, and has `sections`; `text-editor` is a file with ambiguous conflict markers that can only be resolved in an editor. 2. Add a `content_path` field pointing to a JSON representation of the file's content for a single file. 3. Hitting `content_path` returns a similar datastructure to the `file`, but without the `content_path` and `sections` fields, and with a `content` field containing the full contents of the file (with conflict markers). When writing conflicts: 1. Instead of `sections` being at the top level, they are now in a `files` array. This matches the read format better. 2. The `files` array contains file hashes, each of which must contain: a. `new_path` b. `old_path` c. EITHER `sections` (which works as before) or `content` (with the full content of the resolved file).
-
- 06 Oct, 2016 1 commit
-
-
Paco Guzman authored
-
- 03 Oct, 2016 2 commits
-
-
Felipe Artur authored
-
Thomas Balthazar authored
It toggles the 'WIP' prefix in the MR title.
-
- 27 Sep, 2016 1 commit
-
-
Robert Speicher authored
Now a merge request with a blank description will no longer produce a merge commit message like this: ``` Merge branch 'foo' into 'master' Bring the wonders of foo into the world See merge request !7283 ``` What an improvement!
-
- 21 Sep, 2016 2 commits
-
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
- For target project show only environments for target branch or with tags - For source project show only environments for source branch
-
- 20 Sep, 2016 4 commits
-
-
Timothy Andrew authored
- Instead of overriding `create` and `update` in `MergeRequests::BaseService` - Get all merge request service specs passing
-
Timothy Andrew authored
- Don't use `TableReferences` - using `.arel_table` is shorter! - Move some database-related code to `Gitlab::Database` - Remove the `MergeRequest#issues_closed` and `Issue#closed_by_merge_requests` associations. They were either shadowing or were too similar to existing methods. They are not being used anywhere, so it's better to remove them to reduce confusion. - Use Rails 3-style validations - Index for `MergeRequest::Metrics#first_deployed_to_production_at` - Only include `CycleAnalyticsHelpers::TestGeneration` for specs that need it. - Other minor refactorings.
-
Timothy Andrew authored
- Move things common to `Issue` and `MergeRequest` into `Issuable` - Move more database-specific functions into `Gitlab::Database` - Indentation changes and other minor refactorings.
-
Lin Jen-Shin authored
However, if MergeRequest#all_commits_sha would want to handle non-persisted merge request, by judging its name, it should not just give 1 SHA, but all of them. But we don't really care all_commits_sha for non-persisted merge request anyway. So I think we should just ignore that case. Better to not implementing something than implementing it in a wrong and confusing way.
-