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
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>
Fix hooks for web based events with external issue references
The creation of cross references for external issues (which would fail)
is now prevented. This fixes a 500 error and the execution of hooks when
creating a merge request or commenting on one.
Fixes#1650, GH-9333.
This regression might have been introduced by
8f8a8ab32b. There is actually a TODO by
@rspeicher mentioning external issues which is lost (unhandled) in a
later commit.
This fix is related to !766 and !804 which fix a similar issue for hooks for
Git based events.
See merge request !794
Fix post-receive errors on a push when an external issue tracker is configured
### What does this MR do?
This MR improves upon !766, fixing errors upon a git push that occur only when an external issue tracker (not JIRA) is used. This MR takes into account that external issue trackers, such as JIRA, may close issues. Disabling the processing of post-receive commits when an external issue tracker is configured seems like the wrong behavior.
### Why was this MR needed?
When a user adds an issue reference, the refactoring in 8f8a8ab and a6defd157 caused `project.get_issue` to be called, causing `ExternalIssue` to be returned when an external issue tracker was configured. This object does not have a `close` method, as needed in `CloseService`. Nor does it make sense to associate a `SystemNote` with this object.
GitLab EE uses a [special case for JIRA](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/app/services/git_push_service.rb#L87). I would recommend moving this logic into `CloseService` too.
### What are the relevant issue numbers?
* Closes#1700
* Closes#1720
See merge request !804
Refactor web editor
* fix problem with editing non-master branch
* before commit make sure branch exists
* dont allow user change file in one branch and commit to another existing branch
* remove a lot of code duplication
* remove outdated statellite errors
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Fixes#1761
See merge request !773
* fix problem with editing non-master branch
* before commit make sure branch exists
* dont allow user change file in one branch and commit to another existing branch
* remove a lot of code duplication
* remove outdated statellite errors
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Ths commit does next:
* When we remove project we move repository to path+deleted.git
* Then we schedule removal of path+deleted with sidekiq
* If repository move failed we abort project removal
This should help us with NFS issue when project get removed but
repository stayed. The full explanation of problem is below:
* rm -rf project.git
* rm -rf removes project.git/objects/foo
* NFS server renames foo to foo.nfsXXXX because some NFS client (think
* Unicorn) still has the file open
* rm -rf exits, but project.git/objects/foo.nfsXXX still exists
* Unicorn closes the file, the NFS client closes the file (foo), and the
* NFS server removes foo.nfsXXX
* the directory project.git/objects/ still exists => problem
So now we move repository and even if repository removal failed
Repository directory is moved so no bugs with project removed but
repository directory taken. User still able to create new project with
same name. From administrator perspective you can easily find stalled
repositories by searching `*+deleted.git`
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
To prevent loose of group data you need to transfer or remove group
first before you can remove user
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Add to_reference method to referable models
Now there is a single source of information for which attribute a model uses to be referenced, and its special character.
See merge request !641
Dmitriy Zaporozhets
Robert Speicher
Douwe MaanandRobert Speicher
Valery Sizov
Adam Meily
Stan Hu
Daniel Gerhardt
zenati
Arthur Gautier
bugagazavr
