- 27 2月, 2019 1 次提交
-
-
由 Jacopo 提交于
The API get projects/:id/traffic/fetches allows user with write access to the repository to get the number of clones for the last 30 days.
-
- 12 2月, 2019 1 次提交
-
-
由 John Cai 提交于
-
- 09 2月, 2019 1 次提交
-
-
由 Nick Thomas 提交于
-
- 06 2月, 2019 2 次提交
-
-
由 Stan Hu 提交于
This makes it easier to access other project arguments in the future.
-
由 Stan Hu 提交于
When hashed storage is in use, it's helpful to have the project name associated with the request. Closes https://gitlab.com/gitlab-org/gitaly/issues/1394
-
- 04 2月, 2019 2 次提交
-
-
由 Dylan MacKenzie 提交于
-
由 Felipe Artur 提交于
-
- 01 2月, 2019 1 次提交
-
-
由 Semyon Pupkov 提交于
-
- 31 1月, 2019 3 次提交
-
-
由 Kamil Trzciński 提交于
-
由 Tiago Botelho 提交于
Group guests will only be displayed merge requests to projects they have a access level to, higher than Reporter. Visible projects will still display the merge requests to Guests
-
由 Heinrich Lee Yu 提交于
-
- 30 1月, 2019 1 次提交
-
-
由 Adrian Moisey 提交于
-
- 29 1月, 2019 1 次提交
-
-
由 Andreas Brandl 提交于
After the import has finished, we flush (delete) the InternalId records related to the project at hand. This means we're starting over with tracking correct internal id values, a new record will be created automatically when the next internal id is generated. The GitHub importer assigns iid values by using supplied values from GitHub. We skip tracking internal id values during the import in favor of higher concurrency. Deleting any InternalId records after the import has finished is an extra measure to guarantee consistency. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/54270.
-
- 28 1月, 2019 1 次提交
-
-
由 Kamil Trzciński 提交于
-
- 21 1月, 2019 1 次提交
-
-
由 Tiago Botelho 提交于
Group guests will only be displayed merge requests to projects they have a access level to, higher than Reporter. Visible projects will still display the merge requests to Guests
-
- 16 1月, 2019 2 次提交
-
-
由 Yorick Peterse 提交于
This refactors some of the logic used for protecting default branches, in particular Project#after_create_default_branch. The logic for this method is moved into a separate service class. Ideally we'd get rid of Project#after_create_default_branch entirely, but unfortunately Project#after_import depends on it. This means it has to stick around until we also refactor Project#after_import. For branch protection levels we introduce Gitlab::Access::BranchProtection, which provides a small wrapper around Integer based branch protection levels. Using this class removes the need for having to constantly refer to Gitlab::Access::PROTECTION_* constants.
-
由 Yorick Peterse 提交于
This refactors the code used for checking if a user has exceeded the personal projects limit. As part of this refactor the method has been renamed from Project#check_limit to "check_personal_projects_limit", as this name makes it much more clear what the purpose of the method is. Standalone unit tests have also been added, as before we only had a single generic validation test that did not cover all cases. The old implementation of the refactored method also included a `rescue` statement. This code would only run when a project creator was not set. The error that would be added wasn't super useful, especially since there would already be errors for the creator not being present. As none of the other code in the "check_personal_projects_limit" raises, it has been removed.
-
- 14 1月, 2019 2 次提交
-
-
由 Zeger-Jan van de Weg 提交于
In theory the case could happen that the initial linking of the pool fails and so do all the retries that Sidekiq performs. This could lead to data loss. To prevent that case, linking is done before Gits GC too. This makes sure that case doesn't happen.
-
由 Alessio Caiazza 提交于
GitLab Pages supports projects hosted under a subgroup, but not subgroup websites. That means that only the highest-level group supports i.e.: You created a group for your engineering department called `engineering`, a subgroup for all your documentation websites called `docs`,and a project within this subgroup is called `workflows`. Your project URL is `https://gitlab.com/engineering/docs/workflows/`. Once you enable GitLab Pages for this project, the site will live under `https://engineering.gitlab.io/docs/workflows`.
-
- 11 1月, 2019 3 次提交
-
-
由 Fabian Schneider 提交于
-
由 Heinrich Lee Yu 提交于
-
由 Zeger-Jan van de Weg 提交于
Previously the nullification wasn't done, as the only caller would later destroy the model all together. In https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9070 this change was made. This commit is basically a backport before that MR is merged.
-
- 09 1月, 2019 1 次提交
-
-
由 Steve Azzopardi 提交于
The original intention of `get_build` was as a workaround not to violate `CodeReuse/ActiveRecord`. `find_by_id` does the exact same thing but does not violate the rubocop rule.
-
- 08 1月, 2019 5 次提交
-
-
由 Gabriel Mazetto 提交于
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 提交于
Re-use operations controller which already handles tracing settings.
-
由 Reuben Pereira 提交于
-
由 Steve Azzopardi 提交于
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 提交于
`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 1月, 2019 3 次提交
-
-
由 Grzegorz Bizon 提交于
-
由 Stan Hu 提交于
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
-
由 Brett Walker 提交于
We now use `-merge-request` instead of `+merge-request+` in order to support catch all email addresses
-
- 03 1月, 2019 2 次提交
-
-
由 Grzegorz Bizon 提交于
-
由 Grzegorz Bizon 提交于
This commits adds a new class that is supposed to represent Grape API version, like `v3` or `v4`.
-
- 02 1月, 2019 3 次提交
-
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
- 22 12月, 2018 1 次提交
-
-
- 19 12月, 2018 3 次提交
-
-
由 Jarka Košanová 提交于
- 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 提交于
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 提交于
Removing the pipeline_ci_sources_only feature flag introduced in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23353
-