-
Notifications
You must be signed in to change notification settings - Fork 12
Update the architecture page #25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
9fef636
to
bbad667
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't love the positioning of the arrow labels overlapping multiple arrows, but there seems to be very little we can do about that.
bbad667
to
bc6fc86
Compare
It is a good idea to stay up to date, anyway, but in this instance the motivation is to get across the breaking changes in https://github.com/gohugoio/hugo/releases/tag/v0.148.0 that affect how layouts work (something that I am about to use when I introduce support for Graphviz diagrams). Signed-off-by: Johannes Schindelin <[email protected]>
GitGitGadget deploys an Azure Function to act on webhook events. The documentation still points to the old location, but as of gitgitgadget/gitgitgadget@dbe71cb7 (Remove the code of the Azure Function, 2023-08-17), that location is no longer valid, because the respective source code moved to https://github.com/gitgitgadget/gitgitgadget-github-app. Signed-off-by: Johannes Schindelin <[email protected]>
As of gitgitgadget/gitgitgadget#609, GitGitGadget no longer runs on a single Azure Pipelines runner, but instead on GitHub-hosted GitHub Actions runners. Let's adjust the part that described the Azure Pipelines' names and purposes, talking about the GitHub workflows and Actions instead. Signed-off-by: Johannes Schindelin <[email protected]>
We no longer use Azure Pipelines (having traded their flexibility for the increased transparency of GitHub workflows). In other words, the exact steps can be inspected by everyone now, in https://github.com/gitgitgadget-workflows/gitgitgadget-workflows. Signed-off-by: Johannes Schindelin <[email protected]>
We now use GitHub workflows for synchronizing. While in the area, also mentioned the current Git GUI maintainer (this was somehow missed in a5db6b8 (Update git-gui references, 2025-08-21)). Signed-off-by: Johannes Schindelin <[email protected]>
a36b6ca
to
a2aad48
Compare
I force-pushed some changes. Range-diff
|
Updates can be adored here: https://dscho.github.io/gitgitgadget.github.io/architecture |
I did some fiddling with overlapping edges, unlabled edges, label placement and readability. What do you think of
|
I love it! And I integrated your changes as b81468e. See it in action here: https://dscho.github.io/gitgitgadget.github.io/architecture |
I tried to add some Mermaid diagrams, but they simply do not look good. Graphviz offers much better control over the layout. Unfortunately, unlike Mermaid (which is a JavaScript library), Graphviz is a command-line program, and therefore not available in the browser. Fortunately, some helpful people maintain a WebAssembly version of Graphviz, which _is_ a JavaScript library: https://github.com/mdaines/viz-js Unfortunately, unlike Mermaid (which weighs ~25kB), the GraphViz WebAssembly weighs 1.4MB. But that's not quite correct, as Mermaid then loads another half megabyte, whereas `viz-js` does not load anything. The `viz-global.js` file was downloaded via: npm pack @viz-js/[email protected] tar Oxvf viz-js-viz-3.17.0.tgz package/dist/viz-global.js \ >static/js/viz-global.js Signed-off-by: Johannes Schindelin <[email protected]>
There are some issues when adding SVGs inside <svg> HTML elements, e.g. that positioning can be harder than with <img> ones, as pointed out at git/git-scm.com#2052 (comment). Let's use <img> elements instead, passing the SVG via data URLs. There are more benefits to that: For example, most modern browsers allow copying an image into the clipboard that is specified as an `<img>` element, but not `<svg>` ones. Likewise, the "Open Image in New Tab" functionality typically only works with the former but not with the latter. Signed-off-by: Johannes Schindelin <[email protected]>
No need to set a background color, is there? Signed-off-by: Johannes Schindelin <[email protected]>
This can be done like so: ```graphviz {.engine="neato"} digraph diagram { A -> B } ``` Signed-off-by: Johannes Schindelin <[email protected]>
Since the WebAssembly version of Graphviz is not exactly light (1.4MB at the time of writing), and since it is a waste to let everybody re-render the SVG client-side over and over again even though the diagram's definition hasn't changed, let's add a script that performs that rendering "on the server side" (more precisely: during deployment). This script takes no arguments and post-processes the output of Hugo in `public/`. For performance reasons, it requires the list of files that contain Graphviz diagrams. With this here site, it might not matter much because there are only a handful images here. However, I want to reuse the same method on git-scm.com where there _are_ thousands of files that do not contain any Graphviz diagrams, and therefore it is a necessary optimization to process only the files that _do_ contain Graphviz diagrams. To get that list, a new layout and page are added that Hugo processes, identifyng said list of files and writing the result to `public/diagram-list.html`. Since this script runs via Node.JS and therefore lacks the convenient built-in HTML parser of browser-based JavaScript engines, a prerequisite is now to run `npm install` so that the `node-html-parser` package is available. Signed-off-by: Johannes Schindelin <[email protected]>
Since we're generating `<img>` elements anyway, might just as well keep that accessibility support. Signed-off-by: Johannes Schindelin <[email protected]>
This avoids the 1.4MB download on the client-side, in favor of inlined, small SVG elements. Signed-off-by: Johannes Schindelin <[email protected]>
b81468e
to
24de833
Compare
Range-diff
|
@rimrul as before, I pushed to my fork so that it can be seen in action: https://dscho.github.io/gitgitgadget.github.io/architecture |
A picture says more than a thousand words, they say. Note: I originally intended to add two Mermaid diagrams. It turned out, though, that there is too little control over the layout using that method, and I turned to a much more complex yet equally more satisfying solution: Graphviz. Signed-off-by: Johannes Schindelin <[email protected]>
I did some fiddling with overlapping edges, unlabled edges, label placement and readability. Signed-off-by: Matthias Aßhauer <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
24de833
to
9325a7c
Compare
LGTM |
After gitgitgadget/gitgitgadget#609 has been addressed, the architecture is noticeably different. Here is an attempt to visualize the new lay of the land: