When a issue is moved from one project to another, all associated
Markdown text is rewritten in the context of the new project. If the
note contained a link to a commit URL, `CommitRewriter#rewrite` would
fail because `Commit#link_reference_pattern` would match `nil` `commit`
values in the HTML generated from the Markdown. These `nil` values were
passed along to `Project#commits_by` because `Commit#reference_valid?`
was always returning `true`.
To prevent this issue from happening, we tighten up the check for
`Commit#reference_valid?` to look for valid SHA values.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/66666
`Array.reverse_each` is faster than `Array.reverse.each` because:
* reverse.each creates a new array then loops each element
* reverse_each loops in reverse order (no intermediate array created)
In production, we've seen the rendering times of the merge request
widget increase as a result of loading commit data. BatchLoader attempts
to call replace_methods on the lazy object, but this has a significant
performance penalty for modules that have many methods. Disabling this
mode (https://github.com/exAspArk/batch-loader/pull/45) appears to cut
load times by about 50% for MergeRequestsController#show.
Relates to https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/6941
This allows using `CacheMarkdownField` for models that are not backed
by ActiveRecord.
When the including class inherits `ActiveRecord::Base` we include
`Gitlab::MarkdownCache::ActiveRecord::Extension`. This will cause the
markdown fields to be rendered and the generated HTML stored in a
`<field>_html` attribute on the record. We also store the version
used for generating the markdown.
All other classes that include this model will include the
`Gitlab::MarkdownCache::Redis::Extension`. This add the `<field>_html`
attributes to that model and will generate the html in them. The
generated HTML will be cached in redis under the key
`markdown_cache:<class>:<id>`. The class this included in must
therefore respond to `id`.
Private commit emails were introduced in !22560, but some parts of
GitLab were not updated to take account of them. This commit adds
support in places that were missed.
The private commit email is automatically generated in the format:
id-username@noreply.HOSTNAME
GitLab instance admins are able to change the HOSTNAME portion,
that defaults to Gitlab's hostname, to whatever they prefer.
When displaying the pipelines of a project we now preload the following
data:
1. Authors of the commits that belong to these pipelines
2. The number of warnings per pipeline, which is used by
Ci::Pipeline#has_warnings?
== Commit Authors
Previously this data was queried for every Commit separately, leading to
20 SQL queries being executed in the worst case. With an average of 3 to
5 milliseconds per SQL query this could result in 100 milliseconds being
spent in _just_ getting Commit authors.
To preload this data Commit#author now uses BatchLoader (through
Commit#lazy_author), and a separate module
Gitlab::Ci::Pipeline::Preloader is used to ensure all authors are loaded
before they are used.
== Number of warnings
This changes Ci::Pipeline#has_warnings? so it supports preloading of the
number of warnings per pipeline. This removes the need for executing a
COUNT(*) query for every pipeline just to see if it has any warnings or
not.
We saw about 10,000 SQL queries for some commits in the NewNoteWorker,
which stalled the Sidekiq queue for other new notes. The notification
service took up to 8 minutes to process the commits. Avoiding this
N+1 query brings the time down significantly.
Closes#45526
GitLab Bot
Stan Hu
Patrick Bajao
Luke Duncalfe
Kamil Trzciński
Francisco Javier López
Nick Thomas
Tiago Botelho
Paul Slaughter
Sean McGivern
yisiliang
Peter Leitzen
gfyoung
Yorick Peterse
Rémy Coutable
Jan Provaznik
blackst0ne
Oswaldo Ferreira
Omar Mekky
YarNayar
Zeger-Jan van de Weg
Ahmad Sherif