Commit graph

11 commits

Author SHA1 Message Date
GitLab Bot
213bd7e9d3 Add latest changes from gitlab-org/gitlab@master 2021-02-18 12:09:34 +00:00
GitLab Bot
bf217da41b Add latest changes from gitlab-org/gitlab@master 2021-02-11 21:09:00 +00:00
GitLab Bot
559d99e402 Add latest changes from gitlab-org/gitlab@master 2021-02-11 18:09:10 +00:00
Sean McGivern
f9c456bd0c Make performance bar enabled checks consistent
Previously, we called the `peek_enabled?` method like so:

    prepend_before_action :set_peek_request_id, if: :peek_enabled?

Now we don't have a `set_peek_request_id` method, so we don't need that
line. However, the `peek_enabled?` part had a side-effect: it would also
populate the request store cache for whether the performance bar was
enabled for the current request or not.

This commit makes that side-effect explicit, and replaces all uses of
`peek_enabled?` with the more explicit
`Gitlab::PerformanceBar.enabled_for_request?`. There is one spec that
still sets `SafeRequestStore[:peek_enabled]` directly, because it is
contrasting behaviour with and without a request store enabled.

The upshot is:

1. We still set the value in one place. We make it more explicit that
   that's what we're doing.
2. Reading that value uses a consistent method so it's easier to find in
   future.
2019-08-28 17:25:02 +01:00
Sean McGivern
7f102819a5 Fix Peek on Puma
Peek's `Peek.request_id` method doesn't work well with a multi-threaded
server and concurrent requests, because requests can 'steal' another
request's ID, or unset it before it was due.

The upstream change resolves this; the commit here is just to ensure
that GitLab works with that upstream change, mostly by not using
`Peek.request_id` any more (as the method doesn't exist).
2019-08-27 14:15:25 +01:00
Sean McGivern
18cdc5ba6c Remove line profiler from performance bar
1. The output isn't great. It can be hard to find hotspots and, even
   when you do find them, to find why those are hotspots.
2. It uses some jQuery-specific frontend code which we can remove now
   that we don't have this any more.
3. It's only possible to profile the initial request, not any subsequent
   AJAX requests.
2019-07-30 10:00:52 +01:00
Douwe Maan
033b44eb61
Fix various bugs related to relative_url_root in development 2018-05-29 15:03:14 +02:00
blackst0ne
350e26b8a6 [Rails5] Use safe_params instead of params in url_for helpers
This commits replaces `params` with `safe_params` in `url_for` helpers
to resolve security issues [1] and failing specs with the

```
ArgumentError:
  Attempting to generate a URL from non-sanitized request parameters!
  An attacker can inject malicious data into the generated URL, such as
  changing the host. Whitelist and sanitize passed parameters to be secure.
```

error.

[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/45168
2018-04-28 21:35:16 +11:00
Pirate Praveen
c1b416e19f
remove peek performance_bar
Signed-off-by: Rémy Coutable <remy@rymai.me>
2018-04-26 09:03:30 +02:00
Phil Hughes
ab53f7aa13
Fix performance bar spacing 2018-03-21 16:28:07 +00:00
Sean McGivern
a200619d14 Show Ajax requests in performance bar
But first, rewrite the performance bar in Vue:

1. Remove the peek-host gem and replace it with existing code. This also allows
   us to include the host in the JSON response, rather than in the page HTML.
2. Leave the line profiler parts as here-be-dragons: nicer would be a separate
   endpoint for these, so we could use them on Ajax requests too.
3. The performance bar is too fiddly to rewrite right now, so apply the same
   logic to that.

Then, add features! All requests made through Axios are able to be tracked. To
keep a lid on memory usage, only the first two requests for a given URL are
tracked, though. Each request that's tracked has the same data as the initial
page load, with the exception of the performance bar and the line profiler, as
explained above.
2018-03-19 19:06:09 +00:00