Adjust Workflow Graph styling

[bircni]

• Fix workflow dependency graph overflow by making the graph container scrollable (no more clipped DAGs; addresses Workflow Dependencies graph can become unreadable / inaccessible when content overflows the container #37493).
• Improve Actions job list readability by keeping durations fixed-width/right-aligned so long times don’t squeeze job names.
• Make workflow graph layout more intuitive by vertically centering shorter columns to reduce misleading “looks like it depends on” alignments (addresses The workflow summary is not intuitive. #37395).

Screenshot

Fixes #37493
Fixes #37395

[wxiaoguang]

Also this one? The workflow summary is not intuitive. #37395

[bircni]

Also this one? The workflow summary is not intuitive. #37395

yes on it

[wxiaoguang]

Maybe the curves can be adjusted to avoid unnecessary cross points or ambiguous linked steps.

[bircni]

this might extend into a larger refactor - found some other problems

[bircni]

@wxiaoguang what do you think?

[wxiaoguang]

@wxiaoguang what do you think?

UI looks clearer than before.

[bircni]

@wxiaoguang what do you think?

UI looks clearer than before.

if you can help simplifying or improving code structure would be great :)

[wxiaoguang]

@wxiaoguang what do you think?

UI looks clearer than before.

if you can help simplifying or improving code structure would be great :)

Let's make sure (almost) everyone likes the new UI first

[lunny]

It seems there are still some bugs.

[bircni]

It seems there are still some bugs.

how to reproduce?

[lunny]

It seems there are still some bugs.

how to reproduce?

Use the workflows from #36248 (comment)

[bircni]

@lunny fixed

[silverwind]

Such cross-points can't be right.

What is "not right"? By overlaying on a single shared track, all issues go away.

If you mean this cross, devtest does not have it, should be added to devtest.

[wxiaoguang]

Such cross-points can't be right.

What is "not right"? By overlaying on a single shared track, all issues go away.

Read the issues again

• The workflow summary is not intuitive. #37395

[wxiaoguang]

Actually, I don't think we should re-invent the wheel here.

The best and simplest approach should be just using some well-known algorithms. For example: just use the ElkJS from mermaid.

[silverwind]

Not sure whether mermaid would be flexible enough to support the deep customization that's needed here. Might be worth a try though.

[wxiaoguang]

For example: just use the ElkJS from mermaid.

Not sure whether mermaid would be flexible enough to support the deep customization that's needed here. Might be worth a try though.

For example: just use the ElkJS from mermaid. #37497 (comment)

[silverwind]

I'm still not concinved whether it's worth to diverge from GitHub-like rendering too much. ELK renderer would give a different layout for sure. GitHub layout works reasonably well by overlaying paths onto vertical tracks, it's bascially [boxes] [track] [boxes] ... layout.

I actually wonder how this cross looks on GitHub renderer:

[lutinglt]

I'm still not concinved whether it's worth to diverge from GitHub-like rendering too much. ELK renderer would give a different layout for sure. GitHub layout works reasonably well by overlaying paths onto vertical tracks, it's bascially [boxes] [track] [boxes] ... layout.

I actually wonder how this cross looks on GitHub renderer:

If you could provide a task dependency relationship, I would be willing to help with testing

[silverwind]

@wxiaoguang can you provide the workflow file of the screenshot from #37497 (comment)?

[wxiaoguang]

@wxiaoguang can you provide the workflow file of the screenshot from #37497 (comment)?

1. I have provided 790f4b8

Details

2. The end user also provided : The workflow summary is not intuitive. The workflow summary is not intuitive. #37395

[lutinglt]

User Workflow:


https://github.com/lutinglt/workflow_test/actions/runs/25385005787

Test Workflow:


https://github.com/lutinglt/workflow_test/actions/runs/25385005723

[silverwind]

1. Interesting to see that "through box" line, but I think it makes sense as a reasonable tradeoff because rendering outside would be worse.
2. I think GitHub avoids the "cross problem" by layouting the boxes in a way that straight lines never happen except on the first line.

[wxiaoguang]

2. I think GitHub avoids the "cross problem" by layouting the boxes in a way that straight lines never happen except on the first line.

GitHub also renders ambiguous layout for that case.

I don't think GitHub is right, blindly following GitHub is also not right.

I believe something like ElkJS is the right answer, we don't need to write our home-made layout algorithm, and I don't think there will be people interested in maintaining it.

[lutinglt]

From the perspective of someone who has used workflow orchestration tools like Dagster and Airflow, as well as data lineage tools like OpenMetadata, I find GitHub’s flow graph to be really clean and excellent. When dealing with many tasks, a unified vertical line experience is far better than multiple branching lines, because with branching you also need hover highlighting to understand the relationships (trust me, the human eye really dislikes too many lines and isn’t great at parsing them). A unified vertical line also makes the layout more compact.

My observation is that, except for tasks in the first row, as long as downstream tasks are placed in different rows, you can avoid subsequent straight lines. If a downstream task ends up in the same row as its upstream, moving it down to the next row keeps the top-to-bottom data flow direction more natural and curvy. If a downstream task is in a vertical column one row apart, you can just insert a straight line directly.

Compared to GitHub's hover-highlight design for related tasks, most workflow orchestration tools highlight related tasks when you click a card. I think this mainly comes down to the use case — since the actions in GitHub workflows are relatively few and simple, hover works more conveniently.

Of course, if implementing and maintaining something like that turns out to be too difficult, then going with an existing solution like ElkJS is probably the best approach — the GitHub-inspired tweaks are really just a small UX enhancement.

[wxiaoguang]

Do you agree that such layout is right?

• There is no relation between "job 100" and "unit-test".
• They are visually connected together.

If most people agree that it is right, I have nothing more to say.

[lutinglt]

Since hovering with the mouse isn’t a difficult interaction, it can quickly strip away the noise. But maybe it’s just me — when facing many tasks, I’ve personally gotten used to clicking a single task to inspect its dependencies rather than relying on first-glance clarity. That might not reflect what most people prefer, just my own two cents.

[wxiaoguang]

Since hovering with the mouse isn’t a difficult interaction, it can quickly strip away the noise.

How to "hover" when there is no pointer device (mouse)? For example: view the page on a pad?

[lutinglt]

Maybe clicking on a task could toggle the highlight — one click to keep it on, another to turn it off — just like how other workflow orchestration tools handle it.

[wxiaoguang]

just like how other workflow orchestration tools handle it.

Other workflow orchestration tools also generate such ambiguous layout? Don't they have better layout algorithms?

[lutinglt]

They’re using existing solutions like React Flow 🤣

[wxiaoguang]

just like how other workflow orchestration tools handle it.

Other workflow orchestration tools also generate such ambiguous layout? Don't they have better layout algorithms?

They’re using existing solutions like React Flow 🤣

Do other workflow orchestration tools also generate such ambiguous layout?

[lutinglt]

just like how other workflow orchestration tools handle it.

Other workflow orchestration tools also generate such ambiguous layout? Don't they have better layout algorithms?

They’re using existing solutions like React Flow 🤣

Do other workflow orchestration tools also generate such ambiguous layout?

I haven’t come across that behavior in my own use cases.

[silverwind]

The ambiguity resolves when you hover/click one of the boxes, then it highlights the full dependency chain. I think that is clear enough. GitHub sacrifices a bit of clarity with the rendering, but I think it's acceptable. ELK renderer would surely be worse.

[wxiaoguang]

Do other workflow orchestration tools also generate such ambiguous layout?

I haven’t come across that behavior in my own use cases.

Then, since you used "other workflow orchestration tools" as example, if they don't generate ambiguous layouts: why Gitea should learn from GitHub's flawed design.

---

ELK renderer would surely be worse.

I don't understand why it "would surely be worse". Is it your guess? Have you tested it and got proofs? If the ELK layout algorithm is bad, why mermaid uses it.

[wxiaoguang]

They’re using existing solutions like React Flow 🤣

@lutinglt That's what you are referring:

https://github.com/kieler/elkjs
Example Users of elkjs
reactflow - React component for building node-based editors and interactive diagrams

Why not just use elkjs here just like your "workflow orchestration tools"?

[silverwind]

I havent't tried but outcome will likely be like this:

Whether this is better, I'm undecided. The non-alignment of horizontal boxes seems undesirable and I can see complex workflows getting hard to read. It does not look as clean as the current rendering.

[wxiaoguang]

The non-alignment of horizontal boxes seems undesirable and I can see complex workflows getting hard to read.

Maybe you should learn how to use elkjs first.

The box width/height are provided by callers. You tell elkjs to use the same width, then it will use the same width.

[lutinglt]

The difference mainly comes from the intuitive experience when dealing with multiple tasks:

ElkJS (branching lines):
The lines are very accurate, but it’s nearly impossible to trace dependencies just by looking at them. You still need to hover or click on task cards to focus on the relevant cards and lines before you can understand the relationships.

GitHub (unified vertical line):
It’s a bit vague, yet roughly correct. You can get a general sense of task dependencies through the lines at a glance, though for exact dependencies you still need to hover or click on task cards to highlight the related lines and cards.

I think this is the core difference, and it’s why I still prefer GitHub’s design after using many workflow orchestration tools. With many tasks, ElkJS’s lines, while accurate, become noise that my brain and eyes can’t process—at a glance it’s nearly unusable for understanding dependencies. GitHub’s approach may be less precise, but I can still roughly see task dependencies, and it’s correct most of the time. For me, GitHub’s design remains usable at a larger scale with multiple tasks, whereas ElkJS becomes ineffective despite being accurate.

I personally believe the reason you can quickly pick up those rough dependency relationships on GitHub is exactly because of its clean line design. With ElkJS you probably would have already resorted to highlights to find them.

Airflow screenshot:

[silverwind]

The lines are very accurate, but it’s nearly impossible to trace dependencies just by looking at them

Totally agree, the "many lines" ELK rendering is visual overload.

The primary way to gauge execution order is the hover/click interaction which highlights exactly the specific dependency chain I need to see.

GitLab has a similar rendering for their pipelines visualization, but arguable worse than what we currently have.