diff options
Diffstat (limited to 'doc/development')
| -rw-r--r-- | doc/development/changelog.md | 2 | ||||
| -rw-r--r-- | doc/development/distributed_tracing.md | 12 | ||||
| -rw-r--r-- | doc/development/instrumentation.md | 4 | ||||
| -rw-r--r-- | doc/development/performance.md | 26 |
4 files changed, 21 insertions, 23 deletions
diff --git a/doc/development/changelog.md b/doc/development/changelog.md index 814624c7586..5667f58b0c3 100644 --- a/doc/development/changelog.md +++ b/doc/development/changelog.md @@ -99,7 +99,7 @@ automatically. Its simplest usage is to provide the value for `title`: ```text -$ bin/changelog 'Hey DZ, I added a feature to GitLab!' +bin/changelog 'Hey DZ, I added a feature to GitLab!' ``` At this point the script would ask you to select the category of the change (mapped to the `type` field in the entry): diff --git a/doc/development/distributed_tracing.md b/doc/development/distributed_tracing.md index 4776c8348d4..d2810fe89f0 100644 --- a/doc/development/distributed_tracing.md +++ b/doc/development/distributed_tracing.md @@ -27,7 +27,7 @@ no overhead at all. To enable `GITLAB_TRACING`, a valid _"configuration-string"_ value should be set, with a URL-like form: -```console +```sh GITLAB_TRACING=opentracing://<driver>?<param_name>=<param_value>&<param_name_2>=<param_value_2> ``` @@ -90,7 +90,7 @@ documentation](https://www.jaegertracing.io/docs/1.9/getting-started/). If you have Docker available, the easier approach to running the Jaeger all-in-one is through Docker, using the following command: -```console +```sh $ docker run \ --rm \ -e COLLECTOR_ZIPKIN_HTTP_PORT=9411 \ @@ -121,8 +121,8 @@ appropriate configuration string. **TL;DR:** If you are running everything on the same host, use the following value: -```console -$ export GITLAB_TRACING="opentracing://jaeger?http_endpoint=http%3A%2F%2Flocalhost%3A14268%2Fapi%2Ftraces&sampler=const&sampler_param=1" +```sh +export GITLAB_TRACING="opentracing://jaeger?http_endpoint=http%3A%2F%2Flocalhost%3A14268%2Fapi%2Ftraces&sampler=const&sampler_param=1" ``` This configuration string uses the Jaeger driver `opentracing://jaeger` with the following options: @@ -152,7 +152,7 @@ application. When `GITLAB_TRACING` is configured properly, the application will log this on startup: -```console +```sh 13:41:53 gitlab-workhorse.1 | 2019/02/12 13:41:53 Tracing enabled ... 13:41:54 gitaly.1 | 2019/02/12 13:41:54 Tracing enabled @@ -161,7 +161,7 @@ When `GITLAB_TRACING` is configured properly, the application will log this on s If `GITLAB_TRACING` is not configured correctly, this will also be logged: -```console +```sh 13:43:45 gitaly.1 | 2019/02/12 13:43:45 skipping tracing configuration step: tracer: unable to load driver mytracer ``` diff --git a/doc/development/instrumentation.md b/doc/development/instrumentation.md index 777d372ec60..b22a63621dc 100644 --- a/doc/development/instrumentation.md +++ b/doc/development/instrumentation.md @@ -81,9 +81,7 @@ If you're using Pry you can use the `$` command to display the source code of a method (along with its source location), this is easier than running the above Ruby code. In case of the above snippet you'd run the following: -``` -$ Banzai::Renderer.render -``` +- `$ Banzai::Renderer.render` This will print out something along the lines of: diff --git a/doc/development/performance.md b/doc/development/performance.md index 14b3f8204d2..6e6c80b7a7c 100644 --- a/doc/development/performance.md +++ b/doc/development/performance.md @@ -123,7 +123,7 @@ Keeping that in mind, to create a profile, identify (or create) a spec that exercises the troublesome code path, then run it using the `bin/rspec-stackprof` helper, e.g.: -``` +```sh $ LIMIT=10 bin/rspec-stackprof spec/policies/project_policy_spec.rb 8/8 |====== 100 ======>| Time: 00:00:18 @@ -157,22 +157,22 @@ it calls, were being executed. To create a graphical view of the call stack: -```shell -$ stackprof tmp/project_policy_spec.rb.dump --graphviz > project_policy_spec.dot -$ dot -Tsvg project_policy_spec.dot > project_policy_spec.svg +```sh +stackprof tmp/project_policy_spec.rb.dump --graphviz > project_policy_spec.dot +dot -Tsvg project_policy_spec.dot > project_policy_spec.svg ``` To load the profile in [kcachegrind](https://kcachegrind.github.io/): -``` -$ stackprof tmp/project_policy_spec.dump --callgrind > project_policy_spec.callgrind -$ kcachegrind project_policy_spec.callgrind # Linux -$ qcachegrind project_policy_spec.callgrind # Mac +```sh +stackprof tmp/project_policy_spec.dump --callgrind > project_policy_spec.callgrind +kcachegrind project_policy_spec.callgrind # Linux +qcachegrind project_policy_spec.callgrind # Mac ``` It may be useful to zoom in on a specific method, e.g.: -``` +```sh $ stackprof tmp/project_policy_spec.rb.dump --method warm_asset_cache TestEnv#warm_asset_cache (/Users/lupine/dev/gitlab.com/gitlab-org/gitlab-development-kit/gitlab/spec/support/test_env.rb:164) samples: 0 self (0.0%) / 6288 total (36.9%) @@ -225,9 +225,9 @@ may have changed over time. To activate profiling in your local environment, run the following: -``` -$ export RSPEC_PROFILING=yes -$ rake rspec_profiling:install +```sh +export RSPEC_PROFILING=yes +rake rspec_profiling:install ``` This creates an SQLite3 database in `tmp/rspec_profiling`, into which statistics @@ -237,7 +237,7 @@ variable set. Ad-hoc investigation of the collected results can be performed in an interactive shell: -``` +```sh $ rake rspec_profiling:console irb(main):001:0> results.count => 231 |