- 11 Jan, 2019 1 commit
-
-
Fabian Schneider authored
-
- 07 Jan, 2019 5 commits
-
-
Gabriel Mazetto authored
In the previous code, we locked the project during the migration scheduling step, which works fine for small setups, but can be problematic in really big installations. We now moved the logic to inside the worker, so we minimize the time a project will be read-only. We also make sure we only do that if reference counter is `0` (no current operation is in progress).
-
Peter Leitzen authored
Re-use operations controller which already handles tracing settings.
-
Reuben Pereira authored
-
Steve Azzopardi authored
Inside of `Projects::ArtifactsController` and `Projects::BuildArtifactsController` we fetching the build by id using active record directly which violates `CodeReuse/ActiveRecord` rubocop rule. Create `get_build` inside of `project` model which does the same thing.
-
Steve Azzopardi authored
`project.latest_successful_builds_for(ref)` is being used to find a single job all the time. This results into us having to call `find_by` inside of the controller which violates our CodeReuse/ActiveRecord rubocop rule. Refactor `project.latest_successful_builds_for(ref)` to `project.latest_successful_build_for(job_name, ref)` which will execute the `find_by` inside of the model. Also create `project.latest_successful_build_for!(job_name, ref)` which raises an exception instead of returning nil.
-
- 04 Jan, 2019 2 commits
-
-
Grzegorz Bizon authored
-
Stan Hu authored
On GitLab.com, there are hundreds of projects that have visibility levels that are inconsistent with the fork or group settings. Most likely, this happened during a GitLab project import because the validation was bypassed. Attempting to migrate these projects to hashed storage fails even though the migration doesn't touch the visibility settings. Skipping the visibility validation allows the migration to go through. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/55881
-
- 03 Jan, 2019 3 commits
-
-
Brett Walker authored
We now use `-merge-request` instead of `+merge-request+` in order to support catch all email addresses
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
This commits adds a new class that is supposed to represent Grape API version, like `v3` or `v4`.
-
- 02 Jan, 2019 3 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
Douwe Maan authored
-
- 21 Dec, 2018 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 19 Dec, 2018 3 commits
-
-
Jarka Košanová authored
- we now use the hierarchy class also for epics - also rename supports_nested_groups? into supports_nested_objects? - move it to a concern
-
Zeger-Jan van de Weg authored
This action doesn't lean on reduplication, so a short call can me made to the Gitaly server to have the object pool remove its remote to the project pending deletion. https://gitlab.com/gitlab-org/gitaly/blob/f6cd55357/internal/git/objectpool/link.go#L58 When an object pool doesn't have members, this would invalidate the need for a pool. So when a project leaves the pool, the pool will be destroyed on the background. Fixes: https://gitlab.com/gitlab-org/gitaly/issues/1415
-
Francisco Javier López authored
Removing the pipeline_ci_sources_only feature flag introduced in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23353
-
- 13 Dec, 2018 1 commit
-
-
Francisco Javier López authored
-
- 12 Dec, 2018 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 11 Dec, 2018 1 commit
-
-
Yorick Peterse authored
In https://gitlab.com/gitlab-org/release/framework/issues/28 we found that this method was changed a lot over the years: 43 times if our calculations were correct. Looking at the method, it had quite a few branches going on: def create_or_update_import_data(data: nil, credentials: nil) return if data.nil? && credentials.nil? project_import_data = import_data || build_import_data if data project_import_data.data ||= {} project_import_data.data = project_import_data.data.merge(data) end if credentials project_import_data.credentials ||= {} project_import_data.credentials = project_import_data.credentials.merge(credentials) end project_import_data end If we turn the || and ||= operators into regular if statements, we can see a bit more clearly that this method has quite a lot of branches in it: def create_or_update_import_data(data: nil, credentials: nil) if data.nil? && credentials.nil? return else project_import_data = if import_data import_data else build_import_data end if data if project_import_data.data # nothing else project_import_data.data = {} end project_import_data.data = project_import_data.data.merge(data) end if credentials if project_import_data.credentials # nothing else project_import_data.credentials = {} end project_import_data.credentials = project_import_data.credentials.merge(credentials) end project_import_data end end The number of if statements and branches here makes it easy to make mistakes. To resolve this, we refactor this code in such a way that we can get rid of all but the first `if data.nil? && credentials.nil?` statement. We can do this by simply sending `to_h` to `nil` in the right places, which removes the need for statements such as `if data`. Since this data gets written to a database, in ProjectImportData we do make sure to not write empty Hash values. This requires an `unless` (which is really a `if !`), but the resulting code is still very easy to read.
-
- 08 Dec, 2018 14 commits
-
-
Matija Čupić authored
-
Matija Čupić authored
-
Matija Čupić authored
-
Matija Čupić authored
-
Matija Čupić authored
-
Matija Čupić authored
-
Matija Čupić authored
-
Matija Čupić authored
This implements Repository#ambiguous_ref? and checks if a ref is ambiguous before trying to resolve the ref in Project#protected_for?
-
Matija Čupić authored
-
Matija Čupić authored
-
Matija Čupić authored
-
Matija Čupić authored
-
Matija Čupić authored
Reworks Project#resolve_ref to return Gitlab::Git::Branch, Gitlab::Git::Tag or raise an AmbiguousRef error.
-
Matija Čupić authored
-
- 07 Dec, 2018 2 commits
-
-
Zeger-Jan van de Weg authored
When a project is forked, the new repository used to be a deep copy of everything stored on disk by leveraging `git clone`. This works well, and makes isolation between repository easy. However, the clone is at the start 100% the same as the origin repository. And in the case of the objects in the object directory, this is almost always going to be a lot of duplication. Object Pools are a way to create a third repository that essentially only exists for its 'objects' subdirectory. This third repository's object directory will be set as alternate location for objects. This means that in the case an object is missing in the local repository, git will look in another location. This other location is the object pool repository. When Git performs garbage collection, it's smart enough to check the alternate location. When objects are duplicated, it will allow git to throw one copy away. This copy is on the local repository, where to pool remains as is. These pools have an origin location, which for now will always be a repository that itself is not a fork. When the root of a fork network is forked by a user, the fork still clones the full repository. Async, the pool repository will be created. Either one of these processes can be done earlier than the other. To handle this race condition, the Join ObjectPool operation is idempotent. Given its idempotent, we can schedule it twice, with the same effect. To accommodate the holding of state two migrations have been added. 1. Added a state column to the pool_repositories column. This column is managed by the state machine, allowing for hooks on transitions. 2. pool_repositories now has a source_project_id. This column in convenient to have for multiple reasons: it has a unique index allowing the database to handle race conditions when creating a new record. Also, it's nice to know who the host is. As that's a short link to the fork networks root. Object pools are only available for public project, which use hashed storage and when forking from the root of the fork network. (That is, the project being forked from itself isn't a fork) In this commit message I use both ObjectPool and Pool repositories, which are alike, but different from each other. ObjectPool refers to whatever is on the disk stored and managed by Gitaly. PoolRepository is the record in the database.
-
Steve Azzopardi authored
Add a new endpoint `projects/:id/jobs/artifacts/:ref_name/raw/*artifact_path?job=name` which is the close the web URL for consistency sake. This endpoint can be used to download a single file from artifacts for the specified ref and job. closes https://gitlab.com/gitlab-org/gitlab-ce/issues/54626
-
- 06 Dec, 2018 2 commits
-
-
Nick Thomas authored
-
James Lopez authored
Resolve "Can add an existing group member into a group project with new permissions but permissions are not overridden"
-
- 05 Dec, 2018 1 commit
-
-
Francisco Javier López authored
-