Problem to solve

#212 was intended to enable recursive inline expanding of upstream/downstream pipelines. This did not happen, due to miscommunication and time contraints. This issue is a follow up intending to fix that.

We are basically fixing the problem of currently not being able to efficiently check the true origin of the current pipeline or the true effect (downstreams) of the current pipeline

Further details

Solution

Expanding of inline upstream/downstream pipelines is now being made recursive. Making it possible to expand downstreams of downstreams and upstreams of upstreams.

Expanded upstream pipelines do not show downstream of their own which are nonrelated to the current pipeline (already in the application, but probably needs to be pointed out as we are expanding upon related functionality)

Logic of prototype from #2122 (comment 117374817) is still applicable

• Prototype link
• Prototype gif

Specs:

• Spec preview

mockups

Upstream

Loading:

Expanded:

Downstream

Loading:

Multiple + one is expanded

Single + expanded:

FE notes

1. Fetch the main endpoint pipelines/{id}.json
2. Look for triggered_by for the upstream
3. Look for triggered for the downstream pipelines
4. Look for triggered_by.path and triggers[idx].path it only misses the .json Frontend will start polling on click for each upstream/downstream

• it’s not possible to have any upstream/downstream expanded by default bc we won’t have the data. the user has to click on it, we are all ok with this 👍
• We will poll the endpoints for both upstream & downstream pipelines
• Once the user clicks to collapse, we will stop polling. if the user clicks again we fetch again and show a loading again

What does success look like, and how can we measure that?

The user is able to expand upstreams of upstreams and downstreams of downstreams until the first pipeline that set everything into motion VS the last pipeline that was ultimately triggered by it.

Links / references

• #2122 (comment 121841770)
• !8607 (comment 121835732)