Notes on epics promoted from an issue used to get same discussion_id
as the notes from the issue the epic was promoted from, which would
cause problems when trying to reply to the epic discussion.
Move Gitlab::SidekiqMonitor to namespace Gitlab::SidekiqDaemon::Monitor
- Class name and file name change
- File path change to lib/gitlab/sidekiq_daemon/monitor.rb
- Update class usage/reference in other files, including documentation
It consists of two parts:
1. Redirecting users to the configured external storage
1. Allowing the external storage to request the static object(s)
on behalf of the user by means of specific tokens
Part of https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/6829
This makes sure we build the correct variables for testing
translations.
When translating, we could be specifying the variables in different
forms for each id:
- In the singular we could be using a `%{hash}` interpolation
- In the plural we could be using a `%d` interpolation
This changes the tests to accommodate for that: We now use the
variables used in the relevant translation id as the source for the
variables we mix in in specs.
ActiveModel::Serialization is simple in that it recursively calls
`as_json` on each object to serialize everything. However, for a model
like a Project, this can generate a query for every single association,
which can add up to tens of thousands of queries and lead to memory
bloat.
To improve this, we can do several things:
1. We use `tree:` and `preload:` to automatically generate
a list of all preloads that could be used to serialize
objects in bulk.
2. We observe that a single project has many issues, merge requests,
etc. Instead of serializing everything at once, which could lead to
database timeouts and high memory usage, we take each top-level
association and serialize the data in batches.
For example, we serialize the first 100 issues and preload all of
their associated events, notes, etc. before moving onto the next
batch. When we're done, we serialize merge requests in the same way.
We repeat this pattern for the remaining associations specified in
import_export.yml.
This brings a significant refactor to how
we handle `import_export.yml`, merge it with EE
and how we handle that for reader and saver.
This is meant to simplify the code, and remove
a ton of conditions to handle different models
of the structure.
This is also meant to prepare the structure
to extend it much easier, like adding `preload:`
or additional object types when needed.
This does not change the behavior of import/export,
rather unifies and simplifies the current implementation.
Most of the project templates bundled with GitLab have an empty string
set for `external_authorization_classification_label` in their
`project.json`. When imported this overrides the default label set on
the instance, causing the label to appear empty.
This change sets empty labels to nil during import, allowing the
default label to override it and be applied to the project.
Basic `/internal/pages` endpoint that will be used for Pages virtual
domains internal API. The endpoint is currently behind feature flag and
provides authetication similar to how Workhorse is authenticating with
the GitLab.
Detect if pipeline runs for a GitHub pull request
When using a mirror for CI/CD only we register a pull_request
webhook. When a pull_request webhook is received, if the
source branch SHA matches the actual head of the branch in the
repository we create immediately a new pipeline for the
external pull request. Otherwise we store the
pull request info for when the push webhook is received.
When using "only/except: external_pull_requests" we can detect
if the pipeline has a open pull request on GitHub and create or
not the job based on that.
Since it is not possible to dynamically detect if a job is automatically
cancellable or not, a this new attribute is necessary. Moreover, it let
the maintainer of the repo to adjust the behaviour of the auto cancellation
feature to match exactly what he needs.