This exposes `Note`s on Issues & MergeRequests using a
`Types::Notes::NoteableType` in GraphQL.
Exposing notes on a new type can be done by implementing the
`NoteableType` interface on the type. The presented object should
be a `Noteable`.
Adds the groundwork needed in order to persist multi-line suggestions,
while providing the parsing strategy which will be reused for the
**Preview** as well.
This commit, introduced in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23812,
fixes a problem creating a displaying image diff notes when the image
is stored in LFS. The main problem was that `Gitlab::Diff::File` was
returning an invalid valid in `text?` for this kind of files.
It also fixes a rendering problem with other LFS files, like text
ones. They LFS pointer shouldn't be shown when LFS is enabled
for the project, but they were.
Display `formatter` as the sole content of `position` object.
This means `diff_file` data is not referenced, which is the
caseu of "IOError: not opened for reading".
Previously, this wasn't needed: text was normally set to the highlighted
contents anyway. Now, it is: we store different things in text and rich_text.
This caused https://gitlab.com/gitlab-com/production/issues/439.
If a file is deleted, its new_pos is 0 (less than
total_blob_lines), but there is no reason to add the
bottom 'match' line in this case because there is not
extra content which could be expanded.
This currently causes 500's errors when loading the MR page
(Discussion) in a few scenarios.
We were not considering detailed diff headers such as
"--- a/doc/update/mysql_to_postgresql.md\n+++ b/doc/update/mysql_to_postgresql.md"
to crop the diff. In order to address it, we're now using
Gitlab::Diff::Parser, clean the diffs and builds Gitlab::Diff::Line objects
we can iterate and filter on.
We request Gitaly in a N+1 manner to build discussion diffs. Once the diffs are from different revisions, it's hard to make a single request to the service in order to build the whole response.
With this change we solve this problem and simplify a lot fetching this piece of info.
This adds a method to track errors that can be recovered from in
sentry.
It is useful when debugging performance issues, or exceptions that are
hard to reproduce.
Previously, we kept them all in the cache. We don't need the highlight results
for older diffs - if someone does view that (which is rare), we can do the
highlighting on the fly.
Rugged sometimes chops a context line in between bytes, resulting in the context
line having an invalid encoding: https://github.com/libgit2/rugged/issues/716
When that happens, we will try to detect the encoding for the diff, and
sometimes we'll get it wrong. If that difference in encoding results in a
difference in string lengths between the diff and the underlying blobs, we'd
fail to highlight any inline diffs, and return a 500 status to the user.
As we're using the underlying blobs, the encoding is 'correct' anyway, so if the
string range is invalid, we can just discard the inline diff highlighting. We
still report to Sentry to ensure that we can investigate further in future.
Due to the refactoring in !16082, `Blob#batch` no longer falls back
to a default `blob_size_limit`. Since `Repository#batch_blobs` was using
a default `nil` value, this would cause issues in the `Blob#find_by_rugged`
method.
This fix here is to be consistent and use a non-nil default value in
`Repository#batch_blobs`.
The problem was masked in development and tests because Gitaly is always
enabled by default for all features.
Closes#41735
Old merge requests can have diffs without corresponding blobs. (This also may be
possible for commit diffs in corrupt repositories.)
We can't use the `&.` operator on the blobs, because the blob objects are never
nil, but `BatchLoader` instances that delegate to `Blob`. We can't use
`Object#try`, because `Blob` doesn't inherit from `Object`.
`BatchLoader` provides a `__sync` method that returns the delegated object, but
using `itself` also works because it's forwarded, and will work for
non-`BatchLoader` instances too. So the simplest solution is to just use that
with the `&.` operator.
If a merge request was created with a branch name that also matched a tag name,
we'd generate a comparison to or from the tag respectively, rather than the
branch. Merging would still use the branch, of course.
To avoid this, ensure that when we get the branch heads, we prepend the
reference prefix for branches, which will ensure that we generate the correct
comparison.
Bob Van Landuyt
Thong Kuah
Oswaldo Ferreira
Douwe Maan
Mark Chao
Phil Hughes
Rémy Coutable
Francisco Javier López
Sean Nichols
Sean McGivern
Takuya Noguchi
Zeger-Jan van de Weg
George Tsiolis
Chantal Rollison
Jan Provaznik
Jacob Vosmaer
Stan Hu
Martin Nowak
AlexWayfer
Sean McGivern
Valery Sizov
Alejandro Rodríguez