- 11 12月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 10 12月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 06 12月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 04 12月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 01 12月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 30 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 29 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 28 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 27 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 26 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 23 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 22 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 20 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 19 11月, 2019 2 次提交
-
-
由 GitLab Bot 提交于
-
由 GitLab Bot 提交于
-
- 15 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 14 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 13 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 12 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 07 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 06 11月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 29 10月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 24 10月, 2019 1 次提交
-
-
由 Bob Van Landuyt 提交于
When a user updates a merge request coming from a fork, they should not be able to set `force_remove_source_branch` if they cannot push code to the source project. Otherwise developers of the target project could remove the source branch of the source project by setting this flag through the API.
-
- 22 10月, 2019 2 次提交
-
-
由 GitLab Bot 提交于
-
由 GitLab Bot 提交于
-
- 21 10月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 18 10月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 10 10月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 07 10月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 18 9月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 16 9月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 13 9月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 11 9月, 2019 1 次提交
-
-
由 Can Eldem 提交于
-
- 07 9月, 2019 1 次提交
-
-
由 Jan Provaznik 提交于
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.
-
- 06 9月, 2019 1 次提交
-
-
由 Can Eldem 提交于
-
- 05 9月, 2019 1 次提交
-
-
由 Kerri Miller 提交于
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 9月, 2019 1 次提交
-
-
由 Shinya Maeda 提交于
This commit adds pipeline.type key to PipelineEntity. This key will be used in MR widget in the next iteration.
-
- 16 8月, 2019 1 次提交
-
-
由 Nick Thomas 提交于
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.
-
- 10 8月, 2019 1 次提交
-
-
由 Igor 提交于
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 8月, 2019 1 次提交
-
-
由 Eugenia Grieff 提交于
- Original EE MR: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14827
-