Advanced cache
Fixes#1993
* Build missing cache values in background job after each push
* Store commit_count in project table. Refresh in background job
* moved repository size calculation in background job
## Advantages
Every time push is triggered - we build cache for project even without user visiting project page.
That means first visit is as fast as others now. This is especially good for active projects where people have some requests fast because of cache and some slow - because cache was build in their request.
Between cache expired and cache built we we had gap when Linux repo can give 502 error because calculation commits count takes 30 seconds or even more.
Using value from database fix this problem. Before cache is updated you see old value from database. After - you see new one.
Basically this merge request is super win to GitLab. We don't do some heavy operations in user request but instead in background job.
## Temporary problem
After this migration all projects will have `0` commits in database. It fill be replaced with real value on next push. I did not add recalculation to migration because it will last forever on big instances. Can be fixed by adding rake task which will go in background on live instance without downtime
See merge request !986
Fix mentions not being created upon issue/merge request update
New cross-references weren't being added when they were made in an issue or merge request update.
This happened because the relevant `UpdateService`s were making the `notice_added_references` call
after the model had already been updated and saved, so the `changes` attribute was empty and no
cross-references were made at all.
This fixes the bug and adds a bit of testing and a bit of refactoring.
Closes#1773
See merge request !974
Add Irker service configuration options
### What does this MR do?
This MR makes a number of hard-coded Irker parameters configurable in the service settings: Irker server host, port, and default IRC URI. It also removes the "max recipient" limit since the recipient list is configurable only by the project owner, and it makes no sense to update the limit when it is implied in the recipient list already.
### Why was this MR needed?
The existing service assumed that gitlab.com was running an Irker daemon on `localhost` when it was not. Using Irker on gitlab.com thus did not work at all. This MR allows users to provide their own Irker daemons.
### Are there points in the code the reviewer needs to double check?
My main concern is whether allowing a user to specify the server/port combination would have security implications for a host. Given that HipChat and Slack allow users to do this, I didn't think this was doing anything novel.
### What are the relevant issue numbers?
* Closes#1713
* Closes#1714
* Closesgitlab-com/support-forum#139
### Screenshots
### Before
### After
See merge request !930
If you are already sorting in descending order in the created_at,
it is run twice when you run the .recent.
It has passed in the string 'created_at DESC'.
Ruby on Rails is directly given to the SQL.
It is a slow query in MySQL.
Merge branches inside one repository using rugged instead of satellites
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
cc @rspeicher @DouweM
See merge request !918
write_ was renamed to create_
modify_ was renamed to update_
So now in update action we have next code
def create
can?(current_user, :create_issue, @issue)
end
def update
can?(current_user, :update_issue, @issue)
end
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Performance improvements
* store @participants in variable
* store result of subscribed? call into variable
In total it reduce amount of SQL queries for issue or merge_request with 10 comments/participants almost twice.
See merge request !883
* store @participants in variable
* store result of subscribed? call into variable
In total it reduce amount of SQL queries for issue with 10 comments/participants twice.
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Only look up Commit authors/committers by email
- Removes looking up authors/committers by name
- Renames `User.find_for_commit` to `User.find_by_any_email`
Closes#1850
See merge request !878
MergeRequest#show performance improvements
This is a first pass on improving the performance of the `MergeRequests#show` page. Notable changes:
- The "Commits" tab is loaded lazily, so the initial page load should be much faster for MRs with many commits.
- Relative timestamps via `timeago` are only initialized once per load instead of `O(n^2)`. This greatly improves frontend rendering times for a large number of commits.
- Refactored `User.find_for_commit` to use a single ARel-generated SQL query instead of the old method which resulted in one query, and could result in up to three.
See merge request !838
Fix Error 500 when one user attempts to access another's personal, internal snippet
### What does this MR do?
This MR fixes an Error 500 that occurred if one user tried to access another's personal, internal snippet. Steps to reproduce:
### Why was this MR needed?
1. Go to `<hostname>/snippets/new`.
2. Select "Internal".
3. Create a snippet. Save the URL (e.g. `<hostname>/snippets/20`)
4. Logout and sign in as another user.
5. Go to the URL in step 3.
### What are the relevant issue numbers?
Closes#1815
See merge request !854
Dmitriy Zaporozhets
Robert Speicher
Nikita Verkhovin
Stan Hu
Valery Sizov
catatsuy
Douwe Maan
