Docs: Highlight differences between multi-project pipelines and parent-child pipelines
Problem to solve
There are important differences between multi-project pipelines and parent-child pipelines that need to be highlighted in the docs, which would help customers/developers understand the full potential of the feature.
Further details
- Parent-child pipelines run under the same
project + ref + commit sha
. Child pipelines are sub-components of the parent pipeline. - Multi-project pipelines are triggers which means the upstream (triggering) pipeline does not have much control over the downstream (triggered) pipeline aside from choosing the
ref
name and setting variables to be passed downstream.
- The final status of a parent pipeline (like other normal pipelines) can affect the status of the
ref
the pipeline runs against. E.g. if a pipeline fails onmaster
we say thatmaster
is broken. Child pipelines, contrary, are dangling pipelines in a way that they don't directly affect theref
status but it's the parent pipeline that does that. Unless they are triggered usingstrategy:depend
and in that case a child pipeline reports the status to the bridge job in the parent pipeline which can affect the final status of the parent pipeline. - A multi-project pipeline may affect the status of the upstream pipeline if triggered using
strategy:depend
but each pipeline affects the status of theref
in the project they run.
- Parent-child pipelines belong to a virtual namespace that is accessible via the parent pipeline. This allows us to make job artifacts (and reports in particular) from child pipelines visible via the parent pipeline and ultimately displayed in the MR
- Multi-project pipelines are normal pipelines that happened to be triggered by another project but they run in separate namespaces
- Parent-child pipeline hierarchy currently is limited to 2 levels of generation. Meaning that a parent pipeline can trigger multiple child pipelines and in turn each child pipeline can trigger multiple child pipelines:
A -> B -> C
.
- Child pipelines are not directly visible via the Pipeline index page because they are considered sub-components of the parent pipeline. This is to enforce the fact that child pipelines are not standalone and their purpose is to compose the parent pipeline. Child pipelines are visible via their parent pipeline page
- Multi-project pipelines are standalone pipelines because they are normal pipelines that happened to be triggered by an external project. They are all visible via the pipeline index page
- parent and child pipelines are automatically canceled if interruptible, when a new pipeline is created for the same
ref
- multi-project downstream pipelines are not automatically canceled when a new upstream pipeline runs for the same ref. They are considered "external logic". They could automatically be canceled, if interruptible, because a new pipeline is triggered for the same ref on the downstream project, but not because of the upstream pipeline.
Proposal
Who can address the issue
Other links/references
Edited by Fabio Pitino