Add user's last used IP addresses to admin page
This would help admins figure out from where spam is originating.
Screenshot:

See merge request !2381
Fix caching issue where build status was not updating in project dashboard
The project dashboard page would show a stale build status since the caching key did not depend on it. Fix by adding the commit status if CI is applicable.
Closes#3268
See merge request !2353
Do not call API if there is no API URL
Fixes#5878
CE users may not be interested in the new JIRA features. In this case,
we should detect they haven't set an API URL and fallback to the
behavior pre-8.3. This patch does that very easily.
There are planned improvements to JIRA in future releases such as
gitlab-org/gitlab-ce#5541 which will make this more configurable.
See merge request !2341
Suppress e-mails on failed builds if allow_failure is set
Every time I push to GitLab, I get > 2 emails saying a spec failed when I don't care about the benchmarks and others that have `allow_failure` set to `true`.
@ayufan mentioned creating a summary e-mail to prevent getting one e-mail per build, but the latter might actually be desirable. For example, I do want to know if Rubocop errors fail right away.
See merge request !2178
Fix problem with projects ending with .keys #3076Closes#3076
Move route `:username.keys` below project's routes. This allow project's to handle names ending with `.keys`
See merge request !1883
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
Every time I push to GitLab, I get > 2 emails saying a spec failed when
I don't care about benchmarks and other specs that have `allow_failure` set to `true`.
Fix missing date of month in network graph when commits span a month
Closes#3635, #1383
Before:

After:

See merge request !2325
Get "Merge when build succeeds" to work when commits were pushed to MR
target branch while builds were running
The Merge when build succeeds service only merges when the MR is
mergeable (open, not WIP, no conflicts).
When the target branch is updated, all affected MRs have their merge
status set to `unchecked`, and the conflicts check will only happen
when `check_if_can_be_merged` is called, which happens when the MR page
is viewed.
When someone enables the automatic merge, the target branch is updated,
no-one views the MR page again, and the build succeeds, the mergeability
check will fail and the MR will not in fact be merged.
This MR makes sure `check_if_can_be_merged` is always called when MR
mergeability is checked.
See merge request !2304