Check that hooks directory exists before attempting to call realpath
This MR checks that the hooks directories actually exist before attempting to resolve their `realpath`.
Users who attempted to restore from source to an omnibus installation would get ugly errors when running `gitlab-rake gitlab:check`:
```
Errno::ENOENT: No such file or directory @ realpath_rec - /var/opt/gitlab/git-data/repositories/Wanda/www.git/hooks
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/check.rake:488:in `realpath'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/check.rake:488:in `block in check_repos_hooks_directory_is_link'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.1.11/lib/active_record/relation/batches.rb:52:in `block (2 levels) in find_each'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.1.11/lib/active_record/relation/batches.rb:52:in `each'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.1.11/lib/active_record/relation/batches.rb:52:in `block in find_each'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.1.11/lib/active_record/relation/batches.rb:126:in `find_in_batches'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.1.11/lib/active_record/relation/batches.rb:51:in `find_each'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.1.11/lib/active_record/querying.rb:9:in `find_each'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/check.rake:482:in `check_repos_hooks_directory_is_link'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/check.rake:343:in `block (3 levels) in <top (required)>'
Tasks: TOP => gitlab:check => gitlab:gitlab_shell:check
```
Closes#2121#2082
See merge request !1068
Add gitlab-shell to error message to give user a clue that something may be wrong there.
Ran into this in #2082. User was told that repositories were created when they were
not due to hooks symlink being wrong.
Starting with migration `20150717130904` commit count is stored in the
database. For existing projects it defaults to `0` and is updated to the
correct value when commits are pushed.
The newly introduced rake task updates the commit count for all projects
which have not been updated yet.
Refs !986, !989, #2040.
We were using hacks to drop tables etc during a Postgres backup
restore. With this change, we let pg_dump insert the DROP TABLE
statements it needs at the start of the SQL dump.
Fixed rake task gitlab:cleanup:block_removed_ldap_users
Maybe not the most elegant solution, but it works for us.
This closes issue gitlab-org/gitlab-ce#955.
See merge request !338
print validation errors when gitlab-rake gitlab:import:repos fails for project
Currently, when gitlab-rake gitlab:import:repos is not able to import a project it justs prints "Failed trying to create project" to the console. There seems to be no way to find out what exactly has failed. Since the check uses validation, it should at least print the validation issues. That might be a bit cryptic, but may be better than leaving the user in the dark completely.
See merge request !147
Before this it would fail because git hooks automatically prepend
things to the path, which can lead the wrong Ruby version to be called
in which dependencies are not installed.
To make sure that this is correct, the forked_merge_requests commented
out test that depends on this change was uncommented.
For that test to pass, it is also necessary to setup the mock server
on port 3001 under test_env.rb.