streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sblackmon <>
Subject Re: Better managing website SVGs
Date Fri, 25 Nov 2016 21:22:45 GMT
Following up about how we manage DOT/SVG files:

I discovered this morning that has a plugin for managing graphviz files.

After some experimentation, I think I’ve confirmed that the following will work:

a) migrate dot files out of our source control repos and into confluence
b) place them in a page hierarchy aligned with our source hierarchy
c) manage their content from here on out in confluence
d) embed them in the web page as we currently do, using links such as
e) the SVG representation of each diagram gets created by the confluence plugin and exposed
to the web by confluence CMS.

To the degree we want older versions of the diagrams to remain accessible, we can store their
SVGs in the confluence CMS in perpetuity.

I’ve opened STREAMS-462 to do the above, and to add a section to the website describing
how to alter embedded diagrams.

On October 23, 2016 at 10:33:26 AM, sblackmon ( wrote:


In the past I’ve been generating the SVGs (from DOT/graphviz) that are part of the website
as part of the publishing process as described here:

This is preferable to checking in the SVGs in that it doesn’t require every developer to
remember to regenerate the SVG every time any DOT file changes.

The downside is that ubuntu hosts don’t have dot installed so I don’t
see how this step can be hooked up to CI.

Does anyone know of a way to get the dot package installed on those hosts when our builds
run?  Or is it feasible to request hosts with additional packaged installed to make this
possible?  Or any other workable ideas?

If not, I reluctantly propose that anyone changing a dot file will need to regenerate and
check in the new SVG - so that we can run scmpublish from jenkins and omit this tedious manual
step on each website change.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message