- 20 Sep, 2017 2 commits
-
-
Yorick Peterse authored
This makes things simpler as no scheduling is involved. Further we remove the need for running a SELECT + UPDATE just to get the key and update it, whereas we only need an UPDATE when setting last_used_at directly in a request. The added service class takes care of updating Key#last_used_at without using Sidekiq. Further it makes sure we only try to obtain a Redis lease if we're confident that we actually need to do so, instead of always obtaining it. We also make sure to _only_ update last_used_at instead of also updating updated_at. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36663
-
Grzegorz Bizon authored
-
- 19 Sep, 2017 3 commits
-
-
Jacob Vosmaer (GitLab) authored
-
Kamil Trzcinski authored
-
bokebilly authored
-
- 18 Sep, 2017 1 commit
-
-
Grzegorz Bizon authored
Use project full path that can be received from a pipeline object
-
- 15 Sep, 2017 2 commits
-
-
haseeb authored
-
Jacob Vosmaer authored
-
- 14 Sep, 2017 3 commits
-
-
Jacob Vosmaer authored
-
Yorick Peterse authored
This ensures that if a pipeline is present for the last commit on a project's homepage we only run 1 query to get the builds, instead of running 2 queries. See https://gitlab.com/gitlab-org/gitlab-ce/issues/36878#note_40073339 for more information.
-
Yorick Peterse authored
This adds Project#latest_successful_pipeline_for and Project#latest_successful_pipeline_for_default_branch. The 2nd method memoizes the result (taking nil values into account) to ensure the underlying query isn't executed multiple times when viewing a project's homepage. See https://gitlab.com/gitlab-org/gitlab-ce/issues/36878#note_40073607 for more information.
-
- 13 Sep, 2017 7 commits
-
-
Lin Jen-Shin authored
Before this fix, I don't know if those emails would work having newlines in them.
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
- 11 Sep, 2017 2 commits
-
-
Annabel Dunstone Gray authored
This reverts merge request !14148
-
Alex Lossent authored
This enables skipping a lesser housekeeping task (incremental or full repack) by consistently scheduling a higher task (respectively full repack or gc) with the same period. Cf. #34981
-
- 08 Sep, 2017 2 commits
-
-
Rubén Dávila authored
Revert "Merge branch '35012-navigation-add-option-to-change-navigation-color-palette' into 'master'" This reverts merge request !13619
-
Kamil Trzciński authored
Do not use `location.pathname` when accessing environments folders See merge request !2147
-
- 07 Sep, 2017 4 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
-
Annabel Dunstone Gray authored
-
Kamil Trzcinski authored
-
Tiago Botelho authored
-
- 06 Sep, 2017 14 commits
-
-
Michael Kozono authored
-
Michael Kozono authored
-
Michael Kozono authored
-
Michael Kozono authored
…when needed
-
Kamil Trzcinski authored
-
Annabel Dunstone Gray authored
-
Rubén Dávila authored
-
Kamil Trzcinski authored
-
Yorick Peterse authored
This finishes the procedure for migrating events from the old format into the new format. Code no longer uses the old setup and the database tables used during the migration process are swapped, with the old table being dropped. While the database migration can be reversed this will 1) take a lot of time as data has to be coped around 2) won't restore data in the "events.data" column as we have no way of restoring this. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/37241
-
Alexander Keramidas authored
-
micael.bergeron authored
also fix some code styling issues
-
micael.bergeron authored
-
micael.bergeron authored
- only show in merge-requests - show as a little glyph
-
micael.bergeron authored
-