Loading
Wire MFE bake task into asset compilation
What does this MR do and why?
Wires the verified MFE bake into asset compilation — the final integration flip of the registry-direct micro-frontend (MFE) delivery series (see below for the full picture). Nothing in the series executes until this MR lands, which is the safety guard for the whole stack.
- Adds the
gitlab:mfe:bakerake task, which runs the verified baker (part 4 of the stack) and aborts the compile with a clear error if any pinned app fails verification. - Invokes the bake from
gitlab:assets:compile, deliberately outside the assets-SHA cache gate: MFE pins (vendor/mfe.yml) move independently of webpack-relevant sources and are not part of the SHA inputs, so a cache hit must not silently skip baking. - The bake skips entirely unless
mfeis enabled ingitlab.yml, keeping asset builds network-free by default, and never touches the database (Gitlab::Mfe.config_enabled?is made public for exactly this DB-free context; runtime callers keep usingenabled?, which also consults the feature flag).
The series
GitLab-hosted micro-frontend apps are pinned to exact versions and baked into release assets after byte-level verification against the MFE registry (demo registry: https://gitlab-mfe-registry-demo.storage.googleapis.com). The work is split into five small stacked MRs, merged bottom-up:
| # | MR | Content |
|---|---|---|
| 1 | !249067 (merged) | Vendor pin file and reader |
| 2 | !249068 (closed) | Registry version manifest contract |
| 3 | !249069 (closed) | Baked manifest writer/reader |
| 4 | !249070 (closed) | Verified bake orchestrator |
| 5 | !249071 (closed) | Rake task and asset-compile wiring (this MR) |
Related to #605798 (closed) (MFE Phase 1: verified delivery foundation).
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist.
Edited by Illya Klymov