There was some confusion over whether `code` or `content` is the right
parameter for snippets. Internally, the database stores
`content`. However:
1. Project snippets use `code`. `code` gets remapped in `content` in
`lib/api/project_snippets.rb`.
2. Personal snippets use `content`.
To unify these APIs, allow an alias of `content` to work for project
snippets.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/66673
Instead of sending varied data to Gitaly, and making Gitaly construct
various messages, build the messages first and have Gitaly print
either basic messages or alert messages, in the order they come.
Depends on https://gitlab.com/gitlab-org/gitaly/merge_requests/1410
Previously, we called the `peek_enabled?` method like so:
prepend_before_action :set_peek_request_id, if: :peek_enabled?
Now we don't have a `set_peek_request_id` method, so we don't need that
line. However, the `peek_enabled?` part had a side-effect: it would also
populate the request store cache for whether the performance bar was
enabled for the current request or not.
This commit makes that side-effect explicit, and replaces all uses of
`peek_enabled?` with the more explicit
`Gitlab::PerformanceBar.enabled_for_request?`. There is one spec that
still sets `SafeRequestStore[:peek_enabled]` directly, because it is
contrasting behaviour with and without a request store enabled.
The upshot is:
1. We still set the value in one place. We make it more explicit that
that's what we're doing.
2. Reading that value uses a consistent method so it's easier to find in
future.
This key is useful to reduce the amount of logic needed on the frontend:
if `has_warnings` is true, then the frontend knows that the request in
question has warnings for some metric.
For each DetailedView subclass, we add a `warnings` array to:
1. The top-level response.
2. Each individual call under the `details` key.
We use the `.thresholds` hash on the DetailedView to determine what's a
warning. If that hash is empty (the default), then the warnings array
will always be empty.
A new param with_security_reports was added to
GET /groups/:id/projects API and the code to
support this logic in GroupProjectsFinder and
Project model. Also, a DB index was added to
ci_job_artifacts table to speed up the search
of security reports artifacts for projects
Peek's `Peek.request_id` method doesn't work well with a multi-threaded
server and concurrent requests, because requests can 'steal' another
request's ID, or unset it before it was due.
The upstream change resolves this; the commit here is just to ensure
that GitLab works with that upstream change, mostly by not using
`Peek.request_id` any more (as the method doesn't exist).
This is a follow-up from
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31938.
In GitLab 9.0,
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9661 removed the
`subscribed` flag from the API when the user requested a list of issues
or merge requests since calculating this value triggers extensive
Markdown processing.
In GitLab 12.0 via a4fbf39e, we accidentally reintroduced this
performance regression by changing `IssueBasic` to `Issue` in
`entities.rb`. This showed up as a Gitaly N+1 issue since the Markdown
processing would attempt to extract a commit if it detected a regex that
matched a commit.
We restore the prior behavior by once again removing the `subscribed`
flag for the bulk list of issues and merge requests and add a test to
ensure they aren't reintroduced.
Relates to https://gitlab.com/gitlab-org/gitlab-ce/issues/66202
- When renaming a column concurrently, drop any existing trigger before
attempting to create a new one.
When running migration specs multiple times (as it happens during
local development), the down method of previous migrations are called.
If any of the called methods contains a call to
rename_column_concurrently, a trigger will be created and not removed.
So, the next time a migration spec is run, if the same down method is
executed again, it will cause an error when attempting to create the
trigger (since it already exists). Dropping the trigger if it already
exists will prevent this problem.
- Introducting StageEvents to define the available events
- Define the event pairing rules, since some events are not compatible
- Express default Cycle Analytics stages with the event structure
When we un-escape HTML text to find references in it, we should then
re-escape the whole text again, not only found matches.
Because we replace matches with milestone/label links (which contain
HTML tags we don't want to escape again), we re-escape HTML text
with placeholders instead of these links and then replace placeholders
in the escaped text.
Increase sort options for issues list from updated_at and create_at,
to include more options close to what is required in actual issue list
UI.
This helps us to use REST API for issues list with sorting capabilities
https://gitlab.com/gitlab-org/gitlab-ce/issues/57402
Similar to https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31834,
we see that in https://gitlab.com/gitlab-org/gitlab-ce/issues/65957
there can be hundreds, even thousands, of Gitaly requests in the
`/api/:version/projects/:id/merge_requests/:noteable_id/notes` endpoint.
Previously, the API to retrieve notes generated hundreds of Gitaly calls
to determine whether a system note should be shown to the user. It did
this by:
1. Rendering the Markdown
2. Extracting cross-references from the Markdown
3. Issuing a Gitaly `FindCommit` RPC for every reference to validate
that the commit exists.
The last step is unnecessary because we don't need to display a commit
if the user doesn't have access to the project in the first place.
`RendersNotes#prepare_notes_for_rendering` is already used in
`MergeRequestsController`, which is why we don't see N+1 Gitaly calls
there. We use it here to optimize the note redaction process.
Root namespaces have storage statistics.
This commit allows namespace owners to get those stats via GraphQL
queries like the following one
{
namespace(fullPath: "a_namespace_path") {
rootStorageStatistics {
storageSize
repositorySize
lfsObjectsSize
buildArtifactsSize
packagesSize
wikiSize
}
}
}
Limiting the size of issuable description and comments to 1_000_000,
which is close to ~1MB of ASCII characters, which represents 99.9% of
all descriptions and comments we have in DB at the moment. This should
help prevent DoS attacks when comments contain refference strings.
Also this change updates regexp matching the namespaces paths by
limiting the namespaces paths to Namespace::NUMBER_OF_ANCESTORS_ALLOWED,
as we allow 20 levels deep groups.
see https://gitlab.com/gitlab-org/gitlab-ce/issues/61974#note_191274234
When post-processing relative links to absolute links
RelativeLinkFilter didn't take into consideration that
internal repository data could be exposed for users
that do not have repository access to the project.
This commit solves that by checking whether the user
can `download_code` at this repository, avoiding any
processing of this filter if the user can't.
Additionally, if we're processing for a group (
no project was given), we check if the user can
read it in order to expand the href as an extra.
That doesn't seem necessarily a breach now,
but an extra check doesn't hurt as after all
the user needs to be able to `read_group`.
If we process message that is not designated to us
previously we would fire a separate Thread for that.
We don't need to do it. We can cheaply check if thread
is available, if it is, we can perform expensive operation
then.
This makes:
- very shallow `Middleware::Monitor` to only request tracking
of sidekiq jobs,
- `SidekiqStatus::Monitor` to be responsible to maintain persistent
connection to receive messages,
- `SidekiqStatus::Monitor` to always use structured logging
and instance variables
This adds a middleware to track all threads
for running jobs.
This makes sidekiq to watch for redis-delivered notifications.
This makes be able to send notification to interrupt
running sidekiq jobs.
This does not take into account any native code,
as `Thread.raise` generates exception once the control gets
back to Ruby.
The separate measure should be taken to interrupt gRPC, shellouts,
or anything else that escapes Ruby.
Adding, destroying and toggling emoji previously lacked services and
instead were performed through methods called on Awardable models.
This led to inconsistencies where relevant todos would be marked as done
only when emoji were awarded through our controllers, but not through
the API. Todos could also be marked as done when an emoji was being
removed.
Behaviour changes
- Awarding emoji through the API will now mark a relevant Todo as done
- Toggling an emoji off (destroying it) through our controllers will no
longer mark a relevant Todo as done
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/63372
- Added Gitlab::Ci::Config::Entry::Rules and Gitlab::Ci::Config::Entry::Rules:Rule
to handle lists of Rule objects to be evalauted for job inclusion
- Added `if:` and `changes:` as available Rules::Rule::Clause classes
- Added Rules handling logic to Seed::Build#included? with extra specs
- Use DisallowedKeysValidator to mutually exclude rules: from only:/except: on job config
Current `auth.log` uses `fullpath` and `ip`, while `api_json.log` uses
`remote_ip` and `path` for the same fields. Let's standardize these
namings to make it easier for people working with the data.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/66167
- Add mail interceptor the signs outgoing email with SMIME
- Add lib and helpers to work with SMIME data
- New configuration params for setting up SMIME key and cert files
This functionality is available in the /autocomplete users pseudo-API.
We're attempting to replace that with the canonical API, so it needs
support for this parameter too.
In GitLab 9.0,
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9661 removed the
`subscribed` flag from the API when the user requested a list of issues
or merge requests since calculating this value triggers extensive
Markdown processing.
In GitLab 12.0 via a4fbf39e, we accidentally reintroduced this
performance regression by changing `IssueBasic` to `Issue` in
`entities.rb`. This showed up as a Gitaly N+1 issue since the Markdown
processing would attempt to extract a commit if it detected a regex that
matched a commit.
We restore the prior behavior by once again removing the `subscribed`
flag for the bulk list of issues and merge requests and add a test to
ensure they aren't reintroduced.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/66202
Patrick Bajao
Grzegorz Bizon
Stan Hu
Michael Kozono
Jacob Vosmaer
Andrew Newdigate
Sean McGivern
Victor Zagorodny
Patrick Derichs
Jeremy Jackson
Tiger
Doug Stull
Rémy Coutable
Winnie Hellmann
Lin Jen-Shin
dodocat
Etienne Baqué
Reuben Pereira
Mayra Cabrera
Brett Walker
George Koltsov
Igor
Peter Leitzen
Robert Schilling
Kamil Trzciński
Mike Greiling
Marius Bobin
Adam Hegyi
shampton
John Cai
Jan Provaznik
Nick Thomas
Alexandru Croitor
Thong Kuah
Alessio Caiazza
Balakumar
Kushal Pandya
Paul Okstad
Oswaldo Ferreira
Fabio Pitino
Luke Duncalfe
drew
Douwe Maan
Diego Louzán
Cameron Swords
Alex Kalderimis
Robert Speicher
Felipe Artur
Aleksei Lipniagov