Reduce code complexity on GitPushService#execute
Code complexity for gitlab-ce after this has been refactored:
```
27.3: GitPushService#execute
```
This still needs to be merged into `gitlab-ee` presumably with conflicts... Perhaps we should create another issue for doing that?
I left the code sort of similar to what it was... If I could, I would have refactored most of the code into separate classes, etc. as it breaks probably all SOLID principles.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/13327
See merge request !2784
This ensures that _all_ caches (including any caches normally only
flushed under certain conditions) are flushed whenever a project is
removed. Because cache keys are based on project namespaces (excluding
IDs) not doing so could result in a newly created project re-using old
caches (if the project was re-created using the same name).
Fix duplicated branch creation/deletion Web hooks/service notifications when using Web UI
Similar to 423d2d6, except duplicates occurred only if a Web service (e.g. Slack) were
configured.
When deleting a branch, this is what was happening:
1. DeleteBranchService calls execute_hooks and execute_services
2. The call to repository.rm_branch triggers the GitHooksService.
3. This, in turn, calls GitPushService and then calls the same hooks/services again.
5145706 now makes it no longer necessary for DeleteBranchService and CreateBranchService to execute
the branch hooks/services. Note that tags behave differently in GitTagPushService and GitPushService
is not called.
Closes#10330
See merge request !2763
Instead of flushing the behind/ahead counts for all branches upon every
push we now only flush the cache of branches that actually need to have
these statistics recalculated. There are now basically 2 scenarios and
their effects:
1. A user pushes a commit to the default branch, this results in the
cache being flushed for all branches.
2. A user pushes to a non default branch, this results in _only_ the
cache for that branch being flushed.
The existing code (Repository#expire_cache) remains backwards compatible
with the previous behaviour, the new behaviour is only applied when a
branch name is passed as an argument. This ensures that when for example
a project is deleted the cache for all branches is flushed.
Similar to 423d2d6, except duplicates occurred only if a Web service (e.g. Slack) were
configured.
When deleting a branch, this is what was happening:
1. DeleteBranchService calls execute_hooks and execute_services
2. The call to repository.rm_branch triggers the GitHooksService.
3. This, in turn, calls GitPushService and then calls the same hooks/services again.
5145706 now makes it no longer necessary for DeleteBranchService and CreateBranchService to execute
the branch hooks/services. Note that tags behave differently in GitTagPushService and GitPushService
is not called.
Closes#10330
This caches the output of the following methods:
* Repository#empty?
* Repository#has_visible_content?
* Repository#root_ref
The cache for Repository#has_visible_content? is flushed whenever a
commit is pushed to a new branch or an existing branch is removed.
The cache for Repository#root_ref is only flushed whenever a user
changes the default branch of a project. The cache for Repository#empty?
is never explicitly flushed as there's no need for it.
LDAP Sync blocked user edgecases
Allow GitLab admins to block otherwise valid GitLab LDAP users
(https://gitlab.com/gitlab-org/gitlab-ce/issues/3462)
Based on the discussion on the original issue, we are going to differentiate "normal" block operations to the ldap automatic ones in order to make some decisions when its one or the other.
Expected behavior:
- [x] "ldap_blocked" users respond to both `blocked?` and `ldap_blocked?`
- [x] "ldap_blocked" users can't be unblocked by the Admin UI
- [x] "ldap_blocked" users can't be unblocked by the API
- [x] Block operations that are originated from LDAP synchronization will flag user as "ldap_blocked"
- [x] Only "ldap_blocked" users will be automatically unblocked by LDAP synchronization
- [x] When LDAP identity is removed, we should convert `ldap_blocked` into `blocked`
Mockup for the Admin UI with both "ldap_blocked" and normal "blocked" users:

There will be another MR for the EE version.
See merge request !2242
When deleting a branch, this is what was happening:
1. DeleteBranchService calls EventCreateService and creates an event.
2. The call to repository.rm_branch triggers the GitHooksService.
3. This, in turn, calls GitPushService and then calls EventCreateService again.
5145706c now makes it no longer necessary for DeleteBranchService and CreateBranchService to create an event.
Closes#4304
This fixes an issue where the user_id is not included in the data for
user_add_to_team and user_remove_from_team system hooks. The documentation
already states that the user_id should be included.