Is it possible to enforce a pipeline order within a group and minimise the number of pipelines?

Version: Self-hosted Gitlab CE 16.2.3

I have been handed a group that contains a number of Maven projects in a structure a bit like this:

  |- Common (Utility classes and so forth, depends on root)
  |- Root (Sets versions, dependencies etc)
  |- Project 1 (Depends on Common)
  |- Project 2 (Depends on Common)

The goal is to migrate all these projects from building on Jenkins. These are not Git submodules or anything, the dependencies are solely enforced by Maven. (The actual group has many more projects than just these four.)

I am trying to figure out the best way to manage the pipelines do day-to-day pushes/merges (Commit Tags shouldn’t cause me any trouble). Ideally I want to enforce an order when required. For example, if a developer pushes commits to all the projects at once (possible with IntelliJ), then the the pipelines run in this order:

  1. Root
  2. Common
  3. Project 1, Project 2 (can be in parrallel, the are no interdependencies)

If the developer only pushes commits to Project 1, then only that pipeline needs to run.

If a developer pushes commits to Common, then that and Project 1 and Project 2 need to be built. Although the Project 1 and Project 2 could be done by manually re-running the relevant job on their most recent pipeline; this may well be fine for basic Dev work.

One idea I had was to copy what the current Jenkins builds do and have Root trigger Common, then Common trigger Project 1 and Project 2. The issue with that is that in the first scenario, the intial builds of Project 1 and Project 2 may fail all depending on when they run, then the triggered run passes and this will lead to many emails being sent. If they initially happen to run in the correct order, then I needlessly build Project 1 and Project 2 twice.

I guess what I want to achieve is not just the order, but also only triggering if the child pipeline isn’t already pending.

Is this possible? resource_groups maybe?