- 23 Jan, 2017 1 commit
-
-
Oswaldo Ferreira authored
-
- 15 Jan, 2017 2 commits
-
-
Minqi Pan authored
Signed-off-by:
Rémy Coutable <remy@rymai.me>
-
Semyon Pupkov authored
Passing constant into this option is deprecated in Rails 5.2 https://github.com/rails/rails/commit/8312a0d22212798864f142b5a94805e0baa6c562
-
- 11 Jan, 2017 1 commit
-
-
James Lopez authored
-
- 08 Jan, 2017 1 commit
-
-
Yorick Peterse authored
This column used to be a 32 bits integer, allowing for only a maximum of 2 147 483 647 rows. Given enough users one can hit this limit pretty quickly, as was the case for GitLab.com. Changing this type to bigint (= 64 bits) would give us more space, but we'd eventually hit the same limit given enough users and projects. A much more sustainable solution is to simply drop the "id" column. There were only 2 lines of code depending on this column being present, and neither truly required it to be present. Instead the code now uses the "project_id" column combined with the "user_id" column. This means that instead of something like this: DELETE FROM project_authorizations WHERE user_id = X AND id = Y; We now run the following when removing rows: DELETE FROM project_authorizations WHERE user_id = X AND project_id = Y; Since both user_id and project_id are indexed this should not slow down the DELETE query. This commit also removes the "dependent: destroy" clause from the "project_authorizations" relation in the User and Project models. Keeping this prevents Rails from being able to remove data as it relies on an "id" column being present. Since the "project_authorizations" table has proper foreign keys set up (with cascading removals) we don't need to depend on any Rails logic.
-
- 03 Jan, 2017 2 commits
-
-
Robert Speicher authored
-
James Lopez authored
Also added relevant specs and refactored to_references in a bunch of places to be more consistent.
-
- 24 Dec, 2016 2 commits
-
-
Dmitriy Zaporozhets authored
We cant have project with name 'project' or 'tree' anymore. This merge request containts a migration that will find and rename all projects using reserved names by adding N digit to the end of the name. Signed-off-by:
Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
Grzegorz Bizon authored
This reverts merge request !8286
-
- 23 Dec, 2016 1 commit
-
-
Lin Jen-Shin authored
The name latest implies that it's reverse chronological, and we did expect it that way. https://gitlab.com/gitlab-org/gitlab-ce/issues/25993#note_20429761 > ok, I think markglenfletchera is correct in > https://gitlab.com/gitlab-com/support-forum/issues/1394#note_20399939 > that `Project#latest_successful_builds_for` is giving oldest pipeline > rather than latest pipeline. This is a ~regression introduced by !7333 > where `order(id: :desc)` was removed causing this. The offending change > was: > https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7333/diffs#b22732e5f39e176c7c719fe485847d0fb0564275_92_108 > > The confusion was caused by the `latest` name implication, which > actually didn't order anything, and I think we should add `order(id: > :desc)` to `Ci::Pipeline.latest` otherwise it's confusing that it's not > actually ordered. Closes #25993
-
- 21 Dec, 2016 1 commit
-
-
Markus Koller authored
This adds counters for build artifacts and LFS objects, and moves the preexisting repository_size and commit_count from the projects table into a new project_statistics table. The counters are displayed in the administration area for projects and groups, and also available through the API for admins (on */all) and normal users (on */owned) The statistics are updated through ProjectCacheWorker, which can now do more granular updates with the new :statistics argument.
-
- 20 Dec, 2016 2 commits
-
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
- 19 Dec, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by:
Rémy Coutable <remy@rymai.me>
-
- 16 Dec, 2016 3 commits
-
-
Kamil Trzcinski authored
-
Z.J. van de Weg authored
-
Adam Niedzielski authored
This commit introduces the concept of deployment variables - variables that are collected from deployment services and passed to CI runner during a deployment build. Deployment services specify the variables by overriding "predefined_variables" method. This commit also configures variables for KubernetesService
-
- 15 Dec, 2016 2 commits
-
-
Felipe Artur authored
-
Felipe Artur authored
-
- 14 Dec, 2016 1 commit
-
-
Nick Thomas authored
-
- 08 Dec, 2016 1 commit
-
-
Dmitriy Zaporozhets authored
* add parent_id field to namespaces table to store relation with nested groups * create routes table to keep information about full path of every group and project * project/group lookup by full path from routes table Signed-off-by:
Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 06 Dec, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by:
Rémy Coutable <remy@rymai.me>
-
- 02 Dec, 2016 1 commit
-
-
Oswaldo Ferreira authored
-
- 29 Nov, 2016 1 commit
-
-
Douwe Maan authored
Replace issue access checks with use of IssuableFinder Split from !2024 to partially solve https://gitlab.com/gitlab-org/gitlab-ce/issues/23867 ## Which fixes are in this MR?
⚠ - Potentially untested💣 - No test coverage🚥 - Test coverage of some sort exists (a test failed when error raised)🚦 - Test coverage of return value (a test failed when nil used)✅ - Permissions check tested ### Issue lookup with access check Using `visible_to_user` likely makes these security issues too. See [Code smells](#code-smells). - [x]🚦 app/finders/notes_finder.rb:15 [`visible_to_user`] - [x]🚥 app/views/layouts/nav/_project.html.haml:73 [`visible_to_user`] [`.count`] - [x]✅ app/services/merge_requests/build_service.rb:84 [`issue.try(:confidential?)`] - [x]✅ lib/api/issues.rb:112 [`visible_to_user`] - CHANGELOG: Prevented API returning issues set to 'Only team members' to everyone - [x]✅ lib/api/helpers.rb:126 [`can?(current_user, :read_issue, issue)`] Maybe here too? - [x]✅ lib/gitlab/search_results.rb:53 [`visible_to_user`] ### Previous discussions - [ ] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#b2ff264eddf9819d7693c14ae213d941494fe2b3_128_126 - [ ] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#7b6375270d22f880bdcb085e47b519b426a5c6c7_87_87 See merge request !2031
-
- 23 Nov, 2016 5 commits
-
-
Yorick Peterse authored
Flushing the events cache worked by updating a recent number of rows in the "events" table. This has the result that on PostgreSQL a lot of dead tuples are produced on a regular basis. This in turn means that PostgreSQL will spend considerable amounts of time vacuuming this table. This in turn can lead to an increase of database load. For GitLab.com we measured the impact of not using events caching and found no measurable increase in response timings. Meanwhile not flushing the events cache lead to the "events" table having no more dead tuples as now rows are only inserted into this table. As a result of this we are hereby removing events caching as it does not appear to help and only increases database load. For more information see the following comment: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6578#note_18864037
-
Dmitriy Zaporozhets authored
Signed-off-by:
Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
Ahmad Sherif authored
-
Ahmad Sherif authored
-
Ahmad Sherif authored
Closes #23938
-
- 21 Nov, 2016 1 commit
-
-
Yorick Peterse authored
This refactors repository caching so it's possible to selectively refresh certain caches, instead of just expiring and refreshing everything. To allow this the various methods that were cached (e.g. "tag_count" and "readme") use a similar pattern that makes expiring and refreshing their data much easier. In this new setup caches are refreshed as follows: 1. After a commit (but before running ProjectCacheWorker) we expire some basic caches such as the commit count and repository size. 2. ProjectCacheWorker will recalculate the commit count, repository size, then refresh a specific set of caches based on the list of files changed in a push payload. This requires a bunch of changes to the various methods that may be cached. For one, data should not be cached if a branch used or the entire repository does not exist. To prevent all these methods from handling this manually this is taken care of in Repository#cache_method_output. Some methods still manually check for the existence of a repository but this result is also cached. With selective flushing implemented ProjectCacheWorker no longer uses an exclusive lease for all of its work. Instead this worker only uses a lease to limit the number of times the repository size is updated as this is a fairly expensive operation.
-
- 18 Nov, 2016 5 commits
-
-
Ahmad Sherif authored
Closes #23150
-
Kamil Trzcinski authored
-
Robert Speicher authored
This also updates _some_ specs to use these new methods, just to serve as an example for others going forward, but by no means is this exhaustive. Original implementations at !5992 and !6012. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/20944
-
Z.J. van de Weg authored
This prevents leakage of project names on an endpoint which is unauthenticated and thus open to the world.
-
Z.J. van de Weg authored
-
- 17 Nov, 2016 4 commits
-
-
Z.J. van de Weg authored
-
Kamil Trzcinski authored
-
Z.J. van de Weg authored
-
Z.J. van de Weg authored
This commit includes a couple of thing: - A chatops controller - Mattermost::CommandService - Mattermost::Commands::(IssueService|MergeRequestService) The controller is the point where mattermost, and later slack will have to fire their payload to. This in turn will execute the CommandService. Thats where the authentication and authorization should happen. So far this is not yet implemented. This should happen in later commits. Per subcommand, in case of `/gitlab issue show 123` issue whould be the subcommand, there is a service to parse the data, and fetch the resource. The resource is passed back to the CommandService which structures the data.
-
- 16 Nov, 2016 1 commit
-
-
Valery Sizov authored
-