Preload the app in `production` env, hit it with a single request, and
gather total gem memory consumption data using `derailed exec perf:mem`
from `derailed_benchmarks`. Present the result as MR metrics.
Preload the app in `production` env, hit it with a single request, and
gather total gem memory consumption data using `derailed exec perf:mem`
from `derailed_benchmarks`. Present the result as MR metrics.
Improve Review Apps cleanup when previous deployment failed by only issuing an `helm delete` command
Closes#63639 and #62161
See merge request gitlab-org/gitlab-ce!28661
This includes several changes:
- Rename memory-static to generate-gems-size-metrics-static
- Rename memory-static-objects to generate-gems-memory-metrics-static
- Change generate-gems-size-metrics-static interface. The script now
expect `bundle exec derailed bundle:mem` output as its input. The
script output to stdout, or stderr for error message.
- Change generate-gems-memory-metrics-static interface. The script now
expect `bundle exec derailed bundle:objects` output as its input.
The script output to stdout, or stderr for error message.
- Generate gem size metrics. Script generate-gems-size-metrics-static
extract each gem size from `bundle exec derailed bundle:mem` output.
Save output to metrics file in format: 'gem_size_mb{name="zip"} 0.5'
Two static memory benchmarks will be included in our CI pipeline. It
will load gems from the Gemfile and check the amount of RAM consumed
as well as the number of objects allocated and retained.
Aggregated values will be included as 'metrics' into MRs while full
reports will be downloadable as job artifacts.
Prior to this change, the hooks directory got cleared. That works, but
is not the way to go about it as there's a better way. Setting the env
var this commits sets.
Also, play manual jobs once dependency jobs are done instead of polling
for the dependent jobs to be finished.
Signed-off-by: Rémy Coutable <remy@rymai.me>
It seems the deploy function causes the job to fail if it doesn't
succeed. That wasn't the intent as we want to curl the Review App after
the deploy finished (even if it failed) because sometimes the Review App
is just a bit long to be ready.
This change wraps the Review App deployment with "set +e"/"set -e" to
ensure that the job doesn't fail right away if the deploy fails.
Signed-off-by: Rémy Coutable <remy@rymai.me>
Instead of inserting a row after each example to an external database,
we save the CI profiling reports into the `rspec_profiling` directory
and insert the data in the update-tests-metadata CI stage. This should
make each spec run faster and also reduce the number of PostgreSQL
connections needed by concurrent CI builds.
`scripts/insert-rspec-profiling-data` also inserts one file at a time
via the PostgreSQL COPY command for faster inserts. The one side effect
is that the `created_at` and `updated_at` timestamps aren't available
since they aren't generated in the CSV.
Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/10154
This brings back some of the changes in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20339.
For users using Gitaly on top of NFS, accessing the Git data directly
via Rugged is more performant than Gitaly. This merge request introduces
the feature flag `rugged_find_commit` to activate Rugged paths.
There are also Rake tasks `gitlab:features:enable_rugged` and
`gitlab:features:disable_rugged` to enable/disable these feature
flags altogether.
Part of four Rugged changes identified in
https://gitlab.com/gitlab-org/gitlab-ce/issues/57317.