Write to log if web hook cant be executed. This prevents 500 error when
test web hook with invalid URL and prevent exceptions and retries in
sidekiq
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Update Docker configuration to 7.5.2 + minor improvements
- Update to 7.5.2
- logs are now readable with `docker logs`
- recommend an interactive command line for configuration
See merge request !250
Small UI improvement
Move issue/mr iid in the list to second row.
Because title is more important part when looking at the list of issues. Also different amount numbers in ids make title shifted which is bad from UI perspective
See merge request !1295
Improve issuable form links UX
> The create new label / milestone links should open in a new window / popup to avoid losing information already filled in for a new issue.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/855
See merge request !1291
Improve search ux
When I use search from merge requests page I usually want to see merge requests results. If I do search from wiki pages -> I want to see wiki results first.
With this patch search scope is set to issues if you are on issues controller and same for merge requests and wikis
See merge request !1290
Improve MR reloading
## Theory
Every time you pushed to master it updates merge requests that has master
as target branch. So if you have 50 open merge requests point to master
it will reload all of them every time you push a single commit to
master. The funny thing is that after reloading diff of most merge
requests looks the same.
After this patch we update diff only if we push commit to master that
includes in MR commits list.
For example we have next repository:
feature: A - B - C
master: A
We create merge request with code from feature to master.
MR: B - C
If we push to master commit D - MR will not be reloaded. So picture will
look next:
feature: A - B - C
master: A - D
MR: B - C
And if we push to master commit B - MR will be reloaded. So picture will
look next:
feature: A - B - C
master: A - B
MR: C
## Benchmark
For project with 45 open merge requests to master
Before
```
Benchmark post-receive | Cache and size: 0.060000 0.040000 0.100000 ( 0.379720)
Benchmark post-receive | Push commits selection: 0.130000 0.020000 0.150000 ( 0.149299)
Benchmark post-receive | Update merge requests: 9.180000 2.030000 11.210000 ( 11.971747)
Benchmark post-receive | Process commit messages: 0.140000 0.010000 0.150000 ( 0.168810)
Benchmark post-receive | Push data: 0.020000 0.000000 0.020000 ( 0.016363)
Benchmark post-receive | Push event and services: 0.030000 0.000000 0.030000 ( 0.088062)
```
After
```
Benchmark post-receive | Cache and size: 0.070000 0.030000 0.100000 ( 0.106676)
Benchmark post-receive | Push commits selection: 0.130000 0.020000 0.150000 ( 0.143081)
Benchmark post-receive | Update merge requests: 0.660000 0.210000 0.870000 ( 0.892663)
Benchmark post-receive | Process commit messages: 0.030000 0.000000 0.030000 ( 0.029263)
Benchmark post-receive | Push data: 0.020000 0.000000 0.020000 ( 0.018479)
Benchmark post-receive | Push event and services: 0.030000 0.000000 0.030000 ( 0.038230)
```
- - -
## References
Discussion in gitlab/gitlabhq#1796
See merge request !1288
Update libv8
For some reason I could no longer install the previous version of libv8 on my development machine; this version bump fixes that.
I do not know if/how this change affects production environments.
See merge request !1287
Every time you pushed to master it updates merge requests that has master
as target branch. So if you have 50 open merge requests point to master
it will reload all of them every time you push a single commit to
master. The funny thing is that after reloading diff of most merge
requests looks the same.
After this patch we update diff only if we push commit to master that
includes in MR commits list.
For example we have next repository:
feature: A - B - C
master: A
We create merge requests #1 with code from feature to master.
MR #1: B - C
If we push to master commit D - MR will not be reloaded. So picture will
look next:
feature: A - B - C
master: A - D
MR #1: B - C
And if we push to master commit B - MR will be reloaded. So picture will
look next:
feature: A - B - C
master: A - B
MR #1: C
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Dmitriy Zaporozhets
Sytse Sijbrandij
Sytse Sijbrandij
Vincent Robert
Dmitriy Zaporozhets
Jacob Vosmaer
Marin Jankovski