Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 43,899
    • Issues 43,899
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,394
    • Merge requests 1,394
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #336884
Closed
Open
Created Jul 26, 2021 by Fabio Pitino@fabiopitino🌴Maintainer

Define differences between multi-project and parent-child pipelines

Problem

Multi-project and parent-child pipelines are both mechanisms to create downstream pipelines and have a lot of features in common. But there are fundamental differences between these 2 mechanisms that are not well understood today.

Solution

  • Document differences and describe what tool is best for specific scenarios
  • Define long term vision for both mechanisms

Details

To describe things with a programming analogy:

  • parent-child pipelines are equivalent to breaking down a long procedural code into smaller functions/components.

    • Each component does something specific but they all share the same goal (the parent pipeline's goal).
    • Parameters passed to the main procedure can have an effect to the whole pipeline aggregate (parent + children)
    • The parent pipeline can have a high degree of control on the direct child pipelines by defining which config to use, parameters to propagate through.
    • The parent pipeline is able to expose any artifacts/reports/data created within the aggregate. E.g. MR reports.
  • multi-project pipelines are equivalent to calling an external entity either to receive a service (using strategy:depend) or as a notification (without strategy:depend)

    • The downstream pipeline does something specific for the upstream pipeline but at the same time generic for itself.
    • Parameters passed to the main pipeline shouldn't be passed by default to multi-project downstream pipelines. Only variables specific to the downstream pipeline should be explicitly passed.
    • the upstream pipeline doesn't have much control over the downstream pipeline since it's a black box
    • the upstream pipeline can't directly expose data (artifacts) created by downstream pipelines

Proposal

Develop an opinionated practice and a long term vision for Multi-project and Parent-child

Feature Parent-child expected default behavior Multi-project expected default behavior Current default behavior for both
Pipeline status (strategy) Downstream status should effect upstream (strategy: depend by default). Downstream pipeline does not affect upstream. Downstream pipeline does not affect the status of the upstream.
Variables We should inherit pipeline variables from parent to child. We should not inherit pipeline variables. Downstream pipelines only get YAML variables from the bridge.
Artifacts Artifacts should be accessible. Artifacts should not be accessible. Artifacts from downstream pipelines are not directly visible from the top-level pipeline.
Reports Reports should be accessible MP. Reports should not be accessible. Reports from downstream pipelines are not directly visible from the top-level pipeline.
Cancelling/destroing an upstream pipeline Cascade cancellation to a downstream pipeline Downstream pipeline continue to run Downstream pipeline continues to run

cc @dhershkovitch @furkanayhan @marcel.amirault

Edited Oct 11, 2021 by Dov Hershkovitch
Assignee
Assign to
Time tracking