Previously, we just fetched the latest commit for the given branch when
presenting the resulting commit, but because something could have been
committed to that branch between the time we cherry-picked and the time
we render the result, the wrong commit could have been presented.
Now, we fetch the commit object with the commit SHA returned by the
commit change service, which should always be the correct commit.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/53773
This completely rewrites the SnippetsFinder class from the ground up in
order to improve its performance. The old code was beyond salvaging. It
was complex, included various Rails 5 workarounds, comments that
shouldn't be necessary, and most important of all: it produced a really
poorly performing database query.
As a result, I opted for rewriting the finder from scratch, instead of
trying to patch the existing code. Instead of trying to reuse as many
existing methods as possible, I opted for defining new methods
specifically meant for the SnippetsFinder. This requires some extra code
here and there, but allows us to have much more control over the
resulting SQL queries. It is these changes that then allow us to produce
a _much_ more efficient query.
To illustrate how bad the old query was, we will use my own snippets as
an example. Currently I have 52 snippets, most of which are global ones.
To retrieve these, you would run the following Ruby code:
user = User.find_by(username: 'yorickpeterse')
SnippetsFinder.new(user, author: user).execute
On GitLab.com the resulting query will take between 10 and 15 seconds to
run, producing the query plan found at
https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
the total number of buffers (the sum of all shared hits) is around 185
GB, though the real number is probably (hopefully) much lower as I doubt
simply summing these numbers produces the true total number of buffers
used.
The new query's plan can be found at https://explain.depesz.com/s/wHdN,
and this query takes between 10 and 100-ish milliseconds to run. The
total number of buffers used is only about 30 MB.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
find_by_token is overriden by TokenAuthenticatable which can be easily
missed or confused with #find_by(:token) defined by ActiveRecord. First
step for safer usage is to remove #find_by.
A malicious attacker could craft a request to read arbitrary files on
the system. This change adds a Grape validation to ensure that the
tempfile parameter delivered by the Rack multipart uploader is a
Tempfile type to prevent users from being able to specify arbitrary
filenames.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/53072
This removes the `ForkedProjectLink` model that has been replaced by
the `ForkNetworkMember` and `ForkNetwork` combination. All existing
relations have been adjusted to use these new models.
The `forked_project_link` table has been dropped.
The "Forks" count on the admin dashboard has been updated to count all
`ForkNetworkMember` rows and deduct the number of `ForkNetwork`
rows. This is because now the "root-project" of a fork network also
has a `ForkNetworkMember` row. This count could become inaccurate when
the root of a fork network is deleted.
Was introduced in the time that GitLab still used NFS, which is not
required anymore in most cases. By removing this, the API it calls will
return empty responses. This interface has to be removed in the next
major release, expected to be 12.0.
[master] Confidential issue/private snippet titles can be read by unauthenticated user through GFM markdown API
Closes#2706
See merge request gitlab/gitlabhq!2507