### Problem to solve <!-- What problem do we solve? --> ### Summary There are various display bugs in the pipeline view when a DAG is used. Relationships between steps are more fluid, but the display still works based on the older stage model. This creates confusion when there are complex job relationships. Use a pipeline with a dag and see confusing jumble of connections between jobs. It varies based on the specific DAG configuration, but generally results in this sort of thing: | Problem of non sensical graph | | --- | | <img src="/uploads/e98ac0cb850aef82e3360ebceb7ddba4/image.png" width=300/> | ### Intended users #### Implementor personas * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) #### User personas * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * QA engineer ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> We'll create a PoC that includes a new tab on the pipeline detail view] which showcases new DAG visualization. This will be the first step towards a new pipeline visualization model without immediately replacing the existing one and risking disrupting existing flows. This new tab's graph visualization will focus solely on visualizing execution order in the way of dependency generations (see [video](https://youtu.be/1HYJTkkDs9I)) and each job's dependency lines. There will be no GitLab other data visualized apart from status and job names (so no up/downstreams, no job grouping, no stages, etc) This will fix the core problem of troubleshooting or exploring pipeline architecture. Additionally, it will make it easy to experiment for future iterations and additions together with FE and will enable us to build out this new graph by including more and more GitLab data elements until it can potentially replace the original graph visualisation. | __GitLab additional tab visualisation__ (Note: this visualisation still has artifacts) | | --- | |  | | Reference DAG graph the mockup is based on | | --- | | <img src="/uploads/3883ebf3c3fbc2e5691bd782d004f918/image.png" width=300/> | #### Backend Create an API adjustment which yields parent information (jobs they depend on, if any) of jobs. e.a. `{job: 'release', parents: ['lint', 'build']},` #### Frontend 1. Fix this [graph](https://observablehq.com/@dimitrie/dag-visualisation-based-on-tangled-tree-visualization-ii) to no longer have visual artifacts. 2. Create a separate tab on the [pipeline detail page](https://gitlab.com/gitlab-org/gitlab/pipelines/115210449) which visualizes a new graph with mock pipeline data. We need to showcase the following data: - Columns (dependency generation) - Dependency connection (this is taken care of by the graph) - Job name - Job-status (by including a status icon before the job name) 3. Make this work with the API edit created by BE and release it on GitLab.com #### UX Start working on the building blocks and logic needed to extend the new pipeline visualization, prototype, and ideate together with FE to eventually see how to replace the original graph. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ### Links / references <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->