This code is not being used since the hashed storage
migration has already been enforced, and the Geo legacy
replication code has been removed.

Changelog: removed
EE: true

Joe Woodward authored 1 year ago and Joe Woodward committed 1 year ago

Also removes the rubocop todo

* When `limit:` is not supported
* When table method is unknown

As preparation for #391526
this change refactors the service classes that propagate integrations.

This change:

- Namespaces services into Integrations::Propagation::
- Removes IntegrationList and DataList models

#391526

Changelog: fixed

Changelog: changed

The MR pipelines list view does not seem display code coverage
information. This is moderately expensive to load, so it's better to
omit it.

Also ensure that downstream pipelines respect this option.

This change is behind the feature flag
`merge_request_pipelines_list_disable_coverage`, disabled by default.

We leave the old queue/worker class in place to be safely removed at a
later date after no more jobs are scheduled.

Changelog: other

Also remove its RuboCop TODOs.

Changelog: removed

Part of removal of the feature that was never enabled.

Issue: #435432

Changelog: removed

Joe Woodward authored 1 year ago and Joe Woodward committed 1 year ago

Fixes rubocop offence and removes todo

- add store for onboarding concerns that we want to record
  in order to either analyze on the data side or for future
  triggering of user experiences outside of onboarding in the
  app.
- eventual replacement of `onboarding_step_url` column.
- see &11768

Changelog: other

This change removes the project_import_level column
from the namespace_settings table. It is no longer
needed as a different solution has been implemented
since.

Changelog: other

Remove lib/gitlab/usage_data_counters/editor_unique_counter.rb
Replace it with Internal Events for streamlined functionality

Update Direct Transfer API entities endpoint to include
new `stats` key to show statistics about what relations
are imported. It has 3 counters:
  - `source` - how many records the source instance states there are
  - `fetched` - how many records we read from the downloaded export
  - `imported` - how many records we persisted in the database

Changelog: added

Update yml files with removed file paths

Update remote_stream_upload by passing option for local network

This mutation was introduced as alpha so
it doesn't need to follow the deprecation process.
The mutation is no longer needed so we are removing it.

Changelog: removed

Pre-16.3 migration files were removed and schema
changes moved to db/init_structure.sql file

Changelog: changed

Changelog: removed

Changelog: added
EE: true

Related to #414422

Changelog: removed
EE: true

This change refactors ImportLfsObjectsWorker not to override
StageMethods methods, as it was missing out on some of the logic in
that module.

It also contains a few other changes:

- StageMethods no longer finds the project scoped by its import_state,
  in favour of letting some existing logic
  https://gitlab.com/gitlab-org/gitlab/-/blob/d6dea9aa2c2146f12da00fd1734b4b5af0587590/app/workers/concerns/gitlab/github_import/stage_methods.rb#L55-63
  to log and return if the project's import state is #completed? execute
  instead.
- It no longer logs "stage finished" if the worker hits a rate limit and
  reschedules itself to retry later. Instead it logs "stage retrying
  after rate limit".
- It moves queuing the RefreshImportJidWorker out of try_import, to keep
  that method purely about handling rate limit exceptions in #import.

To catch if any behaviours of StageMethods are overridden,
the tests of the module have been ported to the existing shared examples
group, so we run them per stage importer.

ActivityPub is all about JSON : it's used in endpoints to display
information about various actors (the ActivityPub term for any kind of
resource that generates a feed), as well as in messages exchanged
between servers about what those actors are doing ("activities", in
ActivityPub terminology). For that reason, one of the very first thing
we did when implementing ActivityPub was creating serializers for it, in
the `ActivityPub` namespace, in the merge request
[about displaying the first actor's profile and outbox](!127023).
Those serializers are only used by ActivityPub features behind a
feature flag, for now.

While working on additional features, though, it was made clear that the
architecture for those serializers was not going to work for everything.
First, an actor and an activity usually have different boilerplate, so
it helped distinguish them through an ActorSerializer and an
ActivitySerializer, both inheriting from an ObjectSerializer (referring
to the ActivityStreams' [Object type](https://www.w3.org/TR/activitystreams-vocabulary/#object-types)).

Second, using `BaseSerializer` plural features does not work here.
ActivityStreams paginated collections are
[their own beast](https://www.w3.org/TR/activitystreams-core/#paging).
They are linked lists, with a dedicated document serving as index and
providing links to the various resources - it just does not fit what
BaseSerializer allows to do. So an other serializer,
`ActivityPub::CollectionSerializer` has been added to handler them. This
simplifies a lot previous the architecture that was fighting to make
this fit `BaseSerializer` plural feature through a lot of overriding.

This commit refactors the ActivityPub serializers to reflect that and
pave the way for the features coming after. It does not affect existing
code (the API used so far for the releases actor is unchanged).

This was never really rolled out or monitored, and the idea of adding
alerts to the IDE went unused otherwise.

Changelog: removed

We are removing the namespace catalog now that we have a public catalog

Changelog: removed
EE: true

In order to give some room with a namespace for google cloud platform
integration, specify more accurate namespace for cloud seed files as
cloud_seed/google_cloud.

Changelog: changed

- further effort to remove @resource setting
  and resolve rubocop items

- clarity and better organization
- enables less changes in related !140818

We introduced tracking of database events via Snowplow through multiple
iterations, most recently in
#390827. This was done to
test out whether Snowplow could be used to create a replica of our
database.

Within https://gitlab.com/groups/gitlab-data/-/epics/880#note_1474689144
it's described that the PoC led to discarding Snowplow as a viable
option for data replication. This is also confirmed in
#390827 (comment 1562890019).

Now this is just dead code which can lead to confusion.

This feature flag has been enabled by default since 16.6 and now
it's time to remove it.

Changelog: other

Entry::Rules is shared between the Workflow and Processable entries.
Normally, we support only the if, changes, exists, when, and variables
keys in workflow:rules. Yet, we accidentally allow start_in,
allow_failure, and needs.

In this change, we don't aim to fix this, this will be done in
#436473.

In this change, we aim to simplify and highlight this behavior by
adding allowed_keys in the Rules usage.

Also, in validations, we start using only allowed_when and allowed_keys,
we don't use the class constants anymore.

MR: gitlab.com/gitlab-org/gitlab/-/merge_requests/140659
Issue: gitlab.com/gitlab-org/gitlab/-/issues/423210

Changelog: other