Opportunity Canvas Lite: Parent-child pipelines default behavior change
Instructions
Click to expand
-
Create a ♻ Retrospective Thread to capture future improvements to this issue template -
Complete the sections in the issue template below -
Link any relevant issues or research -
Assign to your Manager -
Assign to VP and EVP of Product for approval @sfwgitlab
@adawar
-
Include VP of UX for visibility @clenneville
-
Record a walk-through of this issue (optional) -
Make a copy of the Opportunity Lite Canvas Meeting - TEMPLATE and fill out the required points. -
Schedule the review. -
Once issue is approved, add the label ~oppty-lite::approved
close issue and share in relevant slack channels -
Follow up on the ♻ Retrospective Thread items and propose changes to this issue's template
Note: If issue is not approved, the issue can be closed without adding any labels.
Recorded Walk-Through
Why Canvas Lite?
I am using the Opportunity Canvas Lite format because this is for an existing category and feature for a understood problem and the solution proposed is leveraging existing patterns.
Customer Pain and Problem
The key persona for this validation is Devon -DevOps Engineer.
Users of parent-child pipelines may expect the parent pipeline to always wait for child pipelines to complete first but this is not the default behavior. Not all users are aware they must manually setup this behavior in the CI configs using strategy:depend
syntax in the yaml file.
Problem Details
Today not all parent-child pipelines are configured with the strategy:depends
syntax which is a strategy that makes the parent pipeline wait for child pipelines to complete before the parent pipeline can complete.
A significant example of why this is problematic is when a parent pipeline is configured to list all artifacts produced by itself and its descendant pipelines. In the absence of the strategy:depends
keyword, a race condition occurs where the parent pipeline could complete before all the child pipelines have completed. The consequence is as soon as the parent pipeline completes, the MR reports shows an incomplete list of artifacts for those generated by the parent pipeline and by some of its child pipelines, but there are missing artifacts for child pipelines that are still running.
Eventually all artifacts are visible in the MR as the remaining child pipelines complete, but until then the MR report is incomplete and thus also inaccurate.
Proposed Solution
Make strategy:depend
the default behavior when parent-child pipelines are used. Because this could be a breaking change, we would target this for the next major release in %14.0.
This change seem to be the natural behavior when using parent-child pipelines because it is reasonable for users of this feature to expect:
- The parent pipeline completes after all child pipelines have completed.
- The parent pipeline reflects the status of the child pipelines (e.g. if a child pipeline fails it should make the parent fail).
- The parent pipeline has access to artifacts generated by its child pipelines in order to show reports in MR without risk of any race conditions preventing access to artifacts of all descendant pipelines.
Business case
RICE
RICE score:
(784,800 x 1 x .8) / 3 = 209,280
Reach
What count of users are you expecting to reach with this feature?
6.0 = Impacts a large percentage (~50% to ~80%) of users (as of Dec 2020 SMAU = 981,000 so 80% is 784,800)
Rationale
Impact
Describe the impact this feature will have for those users.
Medium = 1x
Rationale
Confidence
How confident are you in the problem and solution?
Medium = 80%
Rationale
Effort
How many person months do we estimate this will take to build?
3 people x 1 months = 3 effort
Rationale
Business Case Questions
- Roughly what percent of those users would you expect to be Starter? Premium? Ultimate?
- This question requires data research that will be part of gitlab-org/ux-research#1255 (closed)
- What other companies offer a feature like this?
- CodeFresh offers ability to call child pipelines from parent pipeline
- Jenkins supports parallel job execution in a parent-child job feature
- Notable competitors that do not offer this feature:
- GitHub Actions does not appear to support this feature; a review of their docs Workflow syntax for GitHub Actions does not reveal a yaml syntax for triggering a downstream workflow/pipeline.
- Circle CI does not offer this feature, as noted in their FAQs on Workflows
- When do you intend do deliver this feature?
- Assuming this is a breaking change, the earliest we could deliver is at the next major release in %14.0. I would need to work with Design and Engineering to provide an estimate on the first iteration.
- What would happen if we waited to deliver this feature later than you have planned?
- The parent-child pipeline feature would appear incomplete/broken which would results in user-reported bugs and a general distrust pipeline result (e.g. the MR report) that expects parent pipelines to complete after all child pipelines.
Qualitative Evidence
Feature Maturity Plan
By offering the feature additions outlined in this Canvas Lite, we would expect to make the feature maturity:
-
Viable -
Complete -
Lovable
Feature Development Plan
- What is the minimal change to make progress?
- Add explanation in the UI that MR report of artifacts may be incomplete for parent-child pipelines not using
strategy:depends
- Add explanation in the UI that MR report of artifacts may be incomplete for parent-child pipelines not using
- What are the next steps needed to address the problem?
- Make
strategy:depends
the default for parent-child pipelines
- Make