Move development repository to Gitlab

GitHub was setup initially to allow running advanced CI pipelines to leverage advanced testing.

How exactly this inverted approach going to achieve the same? GitLab does not allow 11 CI jobs with customisations.

So this is not about technical reverting the flood code but rather a significant change to the development and testing process.

Source of Truth and CI

• Source of truth: Drupal.org (GitLab) theme repo.
• CI: only on GitHub (site/integration repo) with your 11 install
  variants.
• Composition in GitHub: vendor copy (plain directory), not
  a submodule.
• Key requirement: The GitHub PR created from a d.o. MR must allow
  extra, non-theme commits by maintainers, and new MR commits
  must keep landing on the same PR branch without blowing away
  those extra commits.

Operating Model: "Overlay PR with Additive Sync"

1. Stable Mapping: One MR → One Long-lived PR Branch

• For d.o. MR !1234, create a fixed branch in the GitHub site repo,
  e.g. dorg/mr-1234.
• Open one PR from that branch. This PR is the place where:
  • The theme changes from the MR are overlaid into the
    theme directory (vendor copy).
  • Maintainers can add extra, non-theme commits to make CI pass
    (composer tweaks, demo content changes, UI Kit pinning, CI
    scaffolding, etc.).

2. Sync Algorithm: Overlay Without Clobbering Maintainer Commits

• On every MR update (new commit or force-push):
  • Compute the MR's delta (MR tip vs MR base) and apply it as
    a 3-way overlay onto the current HEAD of dorg/mr-1234
    but restricted to the theme path.
  • Preserves extra commits on the PR branch (overlay applied on
    top of current HEAD).
• If conflicts occur:
  • Mark PR as "needs conflict resolution," list files, and stop.
  • Maintainer resolves conflicts directly in PR branch.

Guardrail: The bot never edits outside the theme directory.
Non-theme files are left for human commits.

3. Review and Gating

• CI runs on GitHub PR (full site with 11 install variants).
• Review happens on GitHub PR.
• Bot keeps a single status comment on d.o. MR with PR link + CI
  status (updated in place).

4. Merge Contract

• Only merge on Drupal.org after GitHub PR is ✅ green.
• After merge on d.o. merge GitHub PR after MR merges, guarded by check "MR status = merged."

Extra Commits Handling

• Maintainers may add non-theme commits directly to the GitHub PR
  branch.
• Subsequent MR commits continue to overlay into same branch, stacking
  after extra commits.
• If MR changes overlap with extra commits → conflict shown → resolved
  manually in PR.

Moving Tests/Files Into Theme

To minimize site-level commits, move into the theme: - Behat tests
under themes/custom/civictheme/tests/behat/. - Fixtures/assets
used by tests. - Theme-specific composer.json if applicable.

Policies

1. Path boundary: Bot overlays only theme dir (e.g.,
   web/themes/custom/civictheme/**). Out-of-bound MR edits flagged.
2. Single merge truth: Merge theme only on d.o. GitHub PR merges
   gated on "MR merged" status.
3. Conflict handling: Bot posts conflict list; maintainers resolve
   in PR branch.
4. Attribution: PR body links to MR and authors; final credit stays
   in d.o.
5. No force-push by bot: All syncs additive. Maintainers may
   force-push only if necessary.

Lifecycle

1. MR opened/updated on d.o. → Bot creates/updates dorg/mr-<iid> PR
   in GitHub (overlay theme dir).
2. Maintainers add extra commits on PR branch as needed.
3. CI runs (11 variants). Iterate until ✅ green.
4. Merge MR on d.o.
5. After MR merge, merge GitHub PR (gated).
6. Cleanup: Close d.o. MR comment, label PR "completed," archive PR
   branch.

Risks and Mitigations

• Overlay drift: keep PRs short-lived, encourage rebase.\
• Hidden coupling: move fixtures/tests into theme.\
• Premature merge risk: protect GitHub PR with required check ("MR
  merged = true").\
• Binary conflicts: prohibit built artifacts, allow only sources.