An error occurred fetching the project authors.
- 07 Sep, 2019 1 commit
-
-
Jan Provaznik authored
Because we don't have any destroy callbacks (or other logic triggered on event destroy), there is no reason for deleting events inefficiently one by one, instead we can use :delete_all.
-
- 05 Sep, 2019 2 commits
-
-
Can Eldem authored
-
Kerri Miller authored
These are the structural changes for supporting the EE feature of moving "code_owner_approval_required" state from existing on a project to being on the protected branches individually, allowing for CODEOWNER validation on push events.
-
- 03 Sep, 2019 1 commit
-
-
Shinya Maeda authored
This commit adds pipeline.type key to PipelineEntity. This key will be used in MR widget in the next iteration.
-
- 15 Aug, 2019 1 commit
-
-
Nick Thomas authored
Prior to 12.1, rebase status was looked up directly from Gitaly. In https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14417 , a DB column was added to track the status instead. However, we couldn't stop looking at the gitaly status immediately, since some rebases may been running across the upgrade. Now that we're in 12.3, it is safe to remove the direct-to-gitaly lookup. This also happens to fix a 500 error that is seen when viewing an MR for a fork where the source project has been removed. We still look at the Gitaly status in the service, just in case Gitaly and Sidekiq get out of sync - I assume this is possible, and it's a relatively cheap check. Since we atomically check and set `merge_requests.rebase_jid`, we should never enqueue two `RebaseWorker` jobs in parallel.
-
- 09 Aug, 2019 1 commit
-
-
Igor authored
Splits auto-refreshing of MR widget into 2 requests: - the one which uses etag-caching and invalidates the fields on change - the one without caching The idea is to gradually move all the fields to etag-cached endpoint
-
- 08 Aug, 2019 1 commit
-
-
Eugenia Grieff authored
- Original EE MR: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14827
-
- 31 Jul, 2019 1 commit
-
-
Oswaldo Ferreira authored
Concurrent calls to UserMergeToRef RPC updating a single ref can lead to an opaque fail that is being rescued at Gitaly. So this commit adds an exclusive lease to the mergeability check process with the key as the current MR ID.
-
- 29 Jul, 2019 1 commit
-
-
Andreas Brandl authored
We dropped MySQL support and a lot of mysql specific code has been removed in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29608. This comes in from the other direction and removes any `if postgresql?` branches.
-
- 15 Jul, 2019 2 commits
-
-
George Koltsov authored
-
Dmitriy Zaporozhets authored
Next models are affected: * Project * Namespace * Issue * Merge request * CI Trigger * CI Pipeline schedule Signed-off-by:
Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 11 Jul, 2019 1 commit
-
-
George Koltsov authored
This change fixes a bug that prevents projects being imported when there are diff notes present in merge requests. Solves https://gitlab.com/gitlab-org/gitlab-ce/issues/63955
-
- 08 Jul, 2019 1 commit
-
-
Shinya Maeda authored
Today, Pipelines for merge train run on `refs/merge`, however, this causes a race condition that it can be overwritten by CheckMergeabilityService. This patch fixes the problem by generating `refs/train` for those pipelines.
-
- 04 Jul, 2019 1 commit
-
-
Nick Thomas authored
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.
-
- 03 Jul, 2019 1 commit
-
-
Mark Chao authored
-
- 25 Jun, 2019 2 commits
-
-
Fabio Pitino authored
-
Fabio Pitino authored
When a user sets only_allow_merge_if_pipeline_succeeds, also named as "Pipeline must succeed" project setting, we require the pipeline to be present. This solves race condition issues especially with external CI providers when a build is triggered externally but no pipelines are created in GitLab yet. Document that a head pipeline is expected when using "Pipeline must succeed" setting. Also explain limitations with the use of only/except where there may not be any jobs created and the merge request will not be allowed to be merged.
-
- 21 Jun, 2019 1 commit
-
-
Oswaldo Ferreira authored
-
- 20 Jun, 2019 1 commit
-
-
Oswaldo Ferreira authored
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.
-
- 13 Jun, 2019 1 commit
-
-
Nick Thomas authored
-
- 11 Jun, 2019 1 commit
-
-
Oswaldo Ferreira authored
-
- 06 Jun, 2019 1 commit
-
-
Shinya Maeda authored
It abstracts some codes for common methods in AutoMerge::*Services.
-
- 03 Jun, 2019 1 commit
-
-
Shinya Maeda authored
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
-
- 31 May, 2019 3 commits
-
-
Oswaldo Ferreira authored
This introduces payload to the ServiceResponse with the merge ref HEAD commit data
-
Oswaldo Ferreira authored
-
Oswaldo Ferreira authored
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.
-
- 22 May, 2019 1 commit
-
-
Stan Hu authored
Starting with Rails 5, belongs_to now adds a presence validation to the association, and so as of shoulda-matchers 4.0.0 the belong_to matcher follows suit and tests that this validation is there by setting the association to nil and asserting that there are validation errors. This exposed an error with the `validate_branches` method: we need to check the source and target project exist.
-
- 06 May, 2019 1 commit
-
-
Shinya Maeda authored
Refactor
-
- 02 May, 2019 1 commit
-
-
Mark Chao authored
Prevents refspec as branch name, which would bypass branch protection when used in conjunction with rebase. HEAD seems to be a special case with lots of occurrence, so it is considered valid for now. Another special case is `refs/head/*`, which can be imported.
-
- 30 Apr, 2019 1 commit
-
-
Shinya Maeda authored
Due to the nature of pipelines for merge requests, deployments.ref can be a merge request ref instead of a branch name. We support the environment auto-stop hook for this case
-
- 23 Apr, 2019 1 commit
-
-
Jasper Maes authored
Model.new.attributes now also returns encrypted attributes.
-
- 16 Apr, 2019 1 commit
-
-
Matija Čupić authored
This backports the changes from https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10452
-
- 08 Apr, 2019 1 commit
-
-
Oswaldo Ferreira authored
Backports https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161 (code out of ee/ folder).
-
- 02 Apr, 2019 2 commits
-
-
Heinrich Lee Yu authored
-
- 01 Apr, 2019 2 commits
-
-
Francisco Javier López authored
-
Shinya Maeda authored
and add spec Add changelog ok ok
-
- 29 Mar, 2019 1 commit
-
-
Shinya Maeda authored
By using `refs/merge-requests/:iid/head` ok ok Improve naming nicely Add nice tests add nice tests fix some more revert
-
- 28 Mar, 2019 1 commit
-
-
Nick Thomas authored
-
- 27 Mar, 2019 1 commit
-
-
Oswaldo Ferreira authored
Adds the groundwork needed in order to persist multi-line suggestions, while providing the parsing strategy which will be reused for the **Preview** as well.
-