Merge when build succeeds
### What does this MR do?
Adds a button to a MR when the build/ci is running so it can be merged when/if the build is successfull.
### Are there points in the code the reviewer needs to double check?
English spelling and whether or not the grammer is correct.
### Why was this MR needed?
When you expect its all good, and don't want to revisit the current MR it can be accepted allready.
### What are the relevant issue numbers / Feature requests?
Fixes#2640 -- although `Merge if green` is replaced with `Merge when the build succeeds` the general idea is the same.
### Screenshots (if relevant)
### Further considerations
What if there are minor things needed solving, e.g. Rubocop, the current implementation will reset the approved status of the MR. It might be a consideration keep the approval for team member, or even guests. This would require an extra option in the Admin screen, though might add extra value.
#### TODO
- [x] Docs
- [x] Specs
/cc @DouweM @rspeicher
See merge request !1729
Introduce CI documentation for services and languages
This introduces guide for PHP, a bunch of services (databases) and cleans up some docker references.
With this there are bunch of example projects in https://gitlab.com/groups/gitlab-examples.
/cc @JobV @axil
See merge request !1917
Add Builds tab to MR detail page
## Before
## After
Fixes#3907
See merge request !2016
Make tab target selectors less naive
Prior, any of the specified IDs could have been hijacked by a table of
contents header, breaking the tab functionality. For example, a `##
Notes` header would get the id `notes` and prevent the Discussion tab
from being activated.
Closes#3908
See merge request !2023
Prior, any of the specified IDs could have been hijacked by a table of
contents header, breaking the tab functionality. For example, a `##
Notes` header would get the id `notes` and prevent the Discussion tab
from being activated.
Closes#3908
Block LDAP user when they are no longer found in the LDAP server
Currently, if a user is deleted from LDAP the `Gitlab::Ldap::Access.allowed?` method will return `false`, but the user will not be blocked. This means that the user would be able to continue using GitLab if they are already logged in, or when performing Git over SSH operations.
After this change, users will be blocked when they no longer exist in LDAP. There is still a one hour LDAP check cache time in effect, so the change is not immediate. This is noted in the documentation.
cc/ @DouweM @dzaporozhets
See merge request !2022
Build related UI fixes
## Before
## After
See merge request !2015
UI: Add "New X" buttons to dashboard and group issue, MR and milestone indexes
# To do
- [x] Use searchable dropdown since dashboard/group can have a lot of projects. Use select2?
## Before
## After
As you can see, for milestones, groups are listed as well as we can now easily create group milestones.
Fixes#3544 and https://dev.gitlab.org/gitlab/gitlabhq/issues/2581
See merge request !1968
Douwe Maan
Achilleas Pipinellis
Stan Hu
Dmitriy Zaporozhets
Zeger-Jan van de WegandStan Hu
Robert Speicher
Robert Speicher
Drew Blessing
Drew Blessing