<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=632651) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=632651) </details> <!--IssueSummary end--> ## Summary This issue tracks the first slice of track 1 of the monolith decomposition: shrink the monolith by moving code that does not depend on the Rails application into gems, and by giving each transport (REST API and Sidekiq) its own shell that owns its boot and configuration. The slice is split into nine workstreams. Each has its own issue with its plan, merge requests, verification and risks; this issue keeps only what they share. All of them sit under https://gitlab.com/groups/gitlab-org/-/work_items/22390. No call sites change: every moved constant keeps its name and its `lib/` path inside the gem, so each change is a pure move plus wiring. The plan for the platform gems follows https://gitlab.com/gitlab-org/gitlab/-/issues/616907. ## Gem family - `gitlab-platform-core` needs only Ruby and ActiveSupport. It holds generic, domain-agnostic libraries, in the spirit of `gitlab-utils`. Git concepts, markup and diff helpers, and GitLab product concepts stay out of it, even when they have no dependencies; they move into product gems instead. The one deliberate exception is the instance identity helpers such as `Gitlab.com?`, which are the gem's configuration seam into the monolith. - `gitlab-platform-<area>` gems are split by dependency footprint, and each may depend only on `gitlab-platform-core`. The first area is `gitlab-platform-database`, which adds ActiveRecord and `pg`. - Product gems sit outside the platform family: `gitlab-banzai`, `gitlab-ci-config`, `gitlab-diff` and `gitlab-git`. They have no ActiveRecord. Each gem declares ports and the monolith provides the adapters, the same way `config/initializers/mfe.rb` does, and the specs move with the code. Gems get the values they need from the monolith through a `configure` block in an initializer. An input that was never set raises an error that names it, instead of falling back to a silent default. ## Workstreams | Workstream | Summary | Issue | MRs | | --- | --- | --- | --- | | `gitlab-declarative_enum` gem | `DeclarativeEnum` as a gem, without its gettext dependency | #635229 | 1, merged | | `gitlab-platform-core` gem | Generic, domain-agnostic libraries from `lib/gitlab/`, then the instance identity helpers | #635231 | 5 | | `gitlab-platform-database` gem | `Gitlab::Database` helpers that need only ActiveRecord and `pg` | #635232 | 5, 1 merged | | `gitlab-banzai` gem | The Banzai Markdown filters and pipelines, with ports for what the monolith provides | #635233 | 9, 8 merged | | `gitlab-ci-config` gem | CI configuration parsing, starting with `UntrustedRegexp` and the pipeline expression language | #635234 | 4 | | `gitlab-diff` gem | Diff parsing, inline and word diff, and diff formatting, starting with `Gitlab::Diff::Line` and `Gitlab::WordDiff` | #637436 | 1 (!266674) | | `gitlab-git` gem | `Gitlab::Git` and `Gitlab::GitalyClient`, starting with a harness that runs the gem's specs against a real Gitaly | #637437 | 1 (!266682) | | `transports/rest` shell | An Engine that owns the REST API mount and its middleware | #635235 | 2 | | `transports/sidekiq` shell | An Engine that owns the Sidekiq queues file, server configuration and `sidekiq-cluster` | #635236 | 4 | ## Verification Every workstream runs the same checks on each branch, in a container on current `master`: the gem specs and RuboCop for each new gem, RuboCop on every changed monolith file, `bin/rails zeitwerk:check`, frozen lockfiles, and a boundary audit. The checks that are specific to a workstream are listed in its issue. `gitlab-git` specs run against a private Gitaly that the gem's spec helper starts from the binaries `setup-test-env` builds, so they test against the same Gitaly as the monolith. The gem trigger template has a `needs` input for this, which defaults to `clone-gitlab-repo`. Merge requests from the community fork can't be stacked: each one targets `master`, and one that builds on another says so in its description and has to merge after it. ## Open decisions - Gems or Rails Engines for the transport shells. - The boundary tool: Packwerk, Rubydex or none. - How gems whose specs need parent pipeline jobs, such as `gitlab-git` and `setup-test-env`, get those jobs in the dependency-graph gem pipelines.