- 29 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 23 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 16 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 15 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 07 11月, 2019 2 次提交
-
-
由 GitLab Bot 提交于
-
由 GitLab Bot 提交于
-
- 22 10月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 21 10月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 16 10月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 10 10月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 30 9月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 25 9月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 18 9月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 16 9月, 2019 2 次提交
-
-
由 GitLab Bot 提交于
-
由 GitLab Bot 提交于
-
- 13 9月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 29 8月, 2019 1 次提交
-
-
由 Igor 提交于
- Extract MR fields for notes into a separate serializer - Check if pipelines are empty via count
-
- 22 8月, 2019 1 次提交
-
-
由 drew cimino 提交于
-
- 21 8月, 2019 1 次提交
-
-
由 George Koltsov 提交于
Sorting preference functionality has been extracted from `IssuableCollections` to a new `SortingPreference` concern in order to reuse this functionality in projects (and groups in the future).
-
- 13 8月, 2019 1 次提交
-
-
由 drew cimino 提交于
- Use set_pipeline_variables to filter for visible pipelines - Mimic response of nonexistent pipeline if not found - Provide set_pipeline_variables as a before_filter for other actions
-
- 05 7月, 2019 1 次提交
-
-
由 drew cimino 提交于
MergeRequest#all_pipelines fetches Ci::Pipeline records from the source project, so we should specifically check that project for permissions. This was already happening for intra-project merge requests, but in the event that the target and source projects both have private builds, we should ensure that the project permissions are respected.
-
- 04 7月, 2019 1 次提交
-
-
由 Nick Thomas 提交于
This MR introduces tracking of the `rebase_jid` for merge requests. As with `merge_ongoing?`, `rebase_in_progress?` will now return true if a rebase is proceeding in sidekiq. After one release, we should remove the Gitaly-based lookup of rebases. It is much better to track this kind of thing via the database.
-
- 28 6月, 2019 1 次提交
-
-
由 Igor Drozdov 提交于
This commits extracts /merge_requests/1.json?serializer=widget Into a separate /merge_requests/1/widget.json endpoint This will allow to use caching for this request
-
- 23 6月, 2019 1 次提交
-
-
由 Stan Hu 提交于
This eliminates many potential duplicate FindCommit RPCs for the same ref, which often occurs in the RelativeLinkFilter#current_commit call. On the GitLab 12.0 release post, for example, this would save close to 400 RPC calls.
-
- 20 6月, 2019 1 次提交
-
-
由 Oswaldo Ferreira 提交于
This couples the code that transitions the `MergeRequest#merge_status` and refs/merge-requests/:iid/merge ref update. In general, instead of directly telling `MergeToRefService` to update the merge ref, we should rely on `MergeabilityCheckService` to keep both the merge status and merge ref synced. Now, if the merge_status is `can_be_merged` it means the merge-ref is also updated to the latest. We've also updated the logic to be more systematic and less user-based.
-
- 12 6月, 2019 2 次提交
-
-
由 Shinya Maeda 提交于
Currently, merge options is updated on #execute method, however, we should have #update interface to make it explicit.
-
由 Oswaldo Ferreira 提交于
-
- 03 6月, 2019 1 次提交
-
-
由 Shinya Maeda 提交于
We have one auto merge strategy today - Merge When Pipeline Succeeds. In order to add more strategies for Merge Train feature, we abstract the architecture to be more extensible. Removed arguments Fix spec
-
- 01 6月, 2019 1 次提交
-
-
由 Oswaldo Ferreira 提交于
This couples the code that transitions the `MergeRequest#merge_status` and refs/merge-requests/:iid/merge ref update. In general, instead of directly telling `MergeToRefService` to update the merge ref, we should rely on `MergeabilityCheckService` to keep both the merge status and merge ref synced. Now, if the merge_status is `can_be_merged` it means the merge-ref is also updated to the latest. We've also updated the logic to be more systematic and less user-based.
-
- 16 4月, 2019 1 次提交
-
-
由 Matija Čupić 提交于
This backports the changes from https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10452
-
- 05 4月, 2019 1 次提交
-
-
由 Stan Hu 提交于
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26248 added support for deduplicating FindCommit requests using Gitaly ref name caching. However, not all endpoints were covered, and in one case the Gitaly wrapper wasn't actually surrounding the serialization step. We can safely cache ref names between FindCommit calls for #index and #show endpoints for merge requests and pipelines. This can significantly reduce the number of FindCommit requests.
-
- 28 3月, 2019 1 次提交
-
-
由 Stan Hu 提交于
For a given merge request, it's quite common to see duplicate FindCommit Gitaly requests because the Gitaly CommitService caches the request by the commit SHA, not by the ref name. However, most of the duplicate requests use the ref name, so the cache is never actually used in practice. This leads to unnecessary requests that slow performance. This commit allows certain callers to bypass the ref name to OID conversion in the cache. We don't do this by default because it's possible the tip of the branch changes during the commit, which would cause the caller to get stale data. This commit also forces the Ci::Pipeline to use the full ref name so that caching can work for merge requests. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/57083
-
- 27 3月, 2019 1 次提交
-
-
由 Phil Hughes 提交于
-
- 18 3月, 2019 1 次提交
-
-
由 Phil Hughes 提交于
-
- 06 3月, 2019 1 次提交
-
-
由 Phil Hughes 提交于
The user can also toggle between the diff changes and the full file diff. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/19054
-
- 08 2月, 2019 1 次提交
-
-
- 06 2月, 2019 1 次提交
-
-
由 Luke Duncalfe 提交于
-
- 05 2月, 2019 1 次提交
-
-
由 Rubén Dávila 提交于
In order to have an accurate date about the last activity of a User we need to update the last_activity_on field when the User is visiting some basic pages of GitLab like pages related to Dashboards, Projects, Issues and Merge Requests
-
- 29 1月, 2019 1 次提交
-
-
由 Mario de la Ossa 提交于
In order to let users' sorting preferences transfer between devices, we save the preference for issues and MRs (one preference for issues, one for MRs) in the backend inside the UserPreference object
-
- 24 1月, 2019 1 次提交
-
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-