- 23 Nov, 2017 1 commit
-
-
Markus Koller authored
-
- 03 Nov, 2017 1 commit
-
-
Bob Van Landuyt authored
-
- 21 Oct, 2017 1 commit
-
-
Maxim Rydkin authored
-
- 20 Oct, 2017 1 commit
-
-
Maxim Rydkin authored
-
- 03 Oct, 2017 1 commit
-
-
Kamil Trzcinski authored
-
- 28 Sep, 2017 1 commit
-
-
Luke "Jared" Bennett authored
-
- 22 Sep, 2017 1 commit
-
-
Phil Hughes authored
This was caused by the `@projects` value being empty when the current user does not have any personal projects.
-
- 13 Sep, 2017 1 commit
-
-
Brandon Everett authored
-
- 07 Sep, 2017 6 commits
-
-
Yorick Peterse authored
Whenever you push to a branch GitLab will show a button to create a merge request (should one not exist already). The underlying code to display this data was quite inefficient. For example, it involved multiple slow queries just to figure out what the most recent push event was. This commit changes the way this data is retrieved so it's much faster. This is achieved by caching the ID of the last push event on every push, which is then retrieved when loading certain pages. Database queries are only executed if necessary and the cached data is removed automatically once a merge request has been created, or 2 hours after being stored. A trade-off of this approach is that we _only_ track the last event. Previously if you were to push to branch A and B then create a merge request for branch B we'd still show the widget for branch A. As of this commit this is no longer the case, instead we will only show the widget for the branch you pushed to most recently. Once a merge request exists the widget is no longer displayed. Alternative solutions are either too complex and/or too slow, hence the decision was made to settle for this trade-off. Performance Impact ------------------ In the best case scenario (= a user didn't push anything for more than 2 hours) we perform a single Redis GET per page. Should there be cached data we will run a single (and lightweight) SQL query to get the event data from the database. If a merge request already exists we will run an additional DEL to remove the cache key. The difference in response timings can vary a bit per project. On GitLab.com the 99th percentile of time spent in User#recent_push hovers between 100 milliseconds and 1 second, while the mean hovers around 50 milliseconds. With the changes in this MR the expected time spent in User#recent_push is expected to be reduced down to just a few milliseconds. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/35990
-
Mike Greiling authored
-
Maxim Rydkin authored
-
Maxim Rydkin authored
-
Maxim Rydkin authored
-
Maxim Rydkin authored
-
- 06 Sep, 2017 3 commits
-
-
Phil Hughes authored
-
Phil Hughes authored
-
Phil Hughes authored
fixed up Ruby based on review
-
- 05 Sep, 2017 2 commits
-
-
kushalpandya authored
-
Phil Hughes authored
-
- 31 Aug, 2017 1 commit
-
-
Sean McGivern authored
The initializers including this were doing so at the top level, so every object loaded after them had a `current_application_settings` method. However, if someone had rack-attack enabled (which was loaded before these initializers), it would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't have that method. To fix this: 1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need `Object.new.current_application_settings` to work. 2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it like that in several places. 3. Change the initializers to use that new form.
-
- 29 Aug, 2017 1 commit
-
-
Phil Hughes authored
-
- 18 Aug, 2017 5 commits
-
-
Phil Hughes authored
fixed some more breadcrumb titles
-
Phil Hughes authored
-
Phil Hughes authored
[ci skip]
-
Phil Hughes authored
[ci skip]
-
Phil Hughes authored
Closes #35269
-
- 15 Aug, 2017 1 commit
-
-
Yorick Peterse authored
In some cases we pass an Array to this method which would previously fail since Array does not respond to "limit_value". Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/3646
-
- 14 Aug, 2017 2 commits
-
-
Robert Speicher authored
An upcoming update to rubocop-gitlab-security added additional violations.
-
Bob Van Landuyt authored
They seem to confuse some translation tools and aren't rendered in HTML anyway.
-
- 07 Aug, 2017 1 commit
-
-
Yorick Peterse authored
In various places we check if the same relation would return projects. This is done using "any?" which will run a COUNT query with any LIMIT/OFFSET values still applied. To work around all this we introduce 2 helper methods that take care of doing the right thing. This leads to the produced queries being simpler and fewer queries being executed.
-
- 01 Aug, 2017 1 commit
-
-
Gabriel Mazetto authored
-
- 18 Jul, 2017 1 commit
-
-
Bob Van Landuyt authored
So the avatars would be reloaded from their new path
-
- 13 Jul, 2017 2 commits
-
-
Phil Hughes authored
Part of #34903
-
Robin Bobbitt authored
When sign-in is disabled: - skip password expiration checks - prevent password reset requests - don’t show Password tab in User Settings - don’t allow login with username/password for Git over HTTP requests - render 404 on requests to Profiles::PasswordsController
-
- 07 Jul, 2017 1 commit
-
-
Tim Zallmann authored
-
- 05 Jul, 2017 1 commit
-
-
Douwe Maan authored
-
- 30 Jun, 2017 1 commit
-
-
Phil Hughes authored
-
- 26 Jun, 2017 1 commit
-
-
Robin Bobbitt authored
If internal auth is disabled and user is not an LDAP user, present the user with an alert to create a personal access token if he does not have one already.
-
- 21 Jun, 2017 1 commit
-
-
Grzegorz Bizon authored
-
- 19 Jun, 2017 1 commit
-
-
TM Lee authored
-