Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab Enterprise Edition
GitLab Enterprise Edition
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
    • Locked Files
  • Issues 3,590
    • Issues 3,590
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 208
    • Merge Requests 208
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Registry
    • Registry
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLab Enterprise EditionGitLab Enterprise Edition
  • Issues
  • #8688

Closed
Open
Opened Dec 03, 2018 by Dimitrie Hoekstra@dimitrieh
  • Report abuse
  • New issue
Report abuse New issue

Recursively expand upstream/downstream pipelines inline

Problem to solve

#2122 (closed) 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

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:

upstream-loading

Expanded:

upstream-expanded

Downstream

Loading:

downstream-loading

Multiple + one is expanded

multiple-downstreams

Single + expanded:

single-downstream

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)
Edited Feb 05, 2019 by Jason Lenny

Related issues

Assignee
Assign to
Epic
11.8
Milestone
11.8
Assign milestone
Time tracking
None
Due date
No due date
16
Labels
Deliverable GitLab Premium In review Release UX ready backend continuous integration customer depth devops:release devops:verify direction feature frontend pipeline release orchestration
Assign labels
  • View project labels
Reference: gitlab-org/gitlab-ee#8688