rewrite deployment CI task to create releases on Gitlab
Prior to this commit, the deployment CI task runs on a private runner and
uploads release artifacts to www2.graphviz.org. The SSH steps in the deployment
task are currently failing due to connectivity issues. The current maintainers
are unable to fix this as we do not have enough knowledge of how this work flow
was intended to function.
Apart from these concerns, Gitlab have recently introduced support for so-called
“generic packages” [0] to host binary artifacts directly on Gitlab (or its
underlying CDN) as well as the ability to programmatically create releases [1]
on the releases page of a project. The decision was made to simplify the
Graphviz infrastructure and host future releases (both stable and development)
on Gitlab.
This change rewrites the deployment task to (1) run on the Gitlab shared runner
using a release-cli Docker image, (2) upload package artifacts to Graphviz'
generic package, and (3) create a release from this for stable version numbers.
To comprehend the role the generic package container is playing here, note that
generic package version numbers are synthesized from commit SHA and are not
intended to be exposed to users. Users can browse the generic package page [2],
but are only ever expected to be interested in the latest version available
here. In contrast, version numbers on the release page [3] are intended to
correspond to Graphviz stable version numbers. ci/deploy.py handles mapping a
release on this page to its related (synthesized) generic package version.
Fix missing return NULL and remove 1 -Wunused-but-set-variable warning in mmio.c
Fixes https://gitlab.com/graphviz/graphviz/-/issues/1875 although this
problem does not currently manifest itself since the
mm_typecode_to_str function is only used in functions writing Matrix
Market files which none of the Graphviz tools currently does.
Most certainly the unitialized values were not intended to used by the
callers since the return value of the function in this case is set to
a "large" value to indicate failure and the callers have assertions
that seems to guard from using such values by mistake (although a
thorough understanding of the algorithm and minimum ink values are
needed to prove this).
Altough the original author seems to have intended to set them to the
mid point, perhaps as a precautionary measure, the assigment has been
removed and new assertions has been added to the relevant call sites
to garantee that they are never used.
Correct assertion and remove 1 -Wparentheses warning in BinaryHeap.c
Note the operator is changed from assigment to *inequality*. From the
surrounding code it's apparent that the intent was to check that no -1
values are left in the mask array (equality to 1 would also have been
correct).
fix: anticipate no non-normal edges when computing direction with concentrate
With concentrate enabled (`concentrate=true`), the direction of edges is
analyzed in lib/dotgen/conc.c. The loops in `samedir()` did not anticipate that
they may not find a single non-normal edge before hitting the end of an edge
chain. This change removes this assumption.
When using fdp to process a graph, it would try to canonicalize all node names,
regardless of whether they were hosted in refstr_ts or not. The problem with
this is that the canonicalization logic assumes the character pointer passed
into it is within a refstr_t and that therefore it can do pointer subtraction to
get a pointer to the refstr_t itself. This was not true for internally
constructed node names like "%4".
We change this to always go through the refstr logic in agstrdup() when
canonicalizing names. This ensures that the pointer we pass into the
canonicalization logic *is* within a refstr_t. This is based on canon() in
lib/cgraph/output.c. Fixes #236, #1290, #1865.
When using newrank=true and incorrectly putting a node in two clusters, one of
the clusters would end up empty. This broke assumptions in the crossing logic;
e.g. that all clusters have a leader. We fix this by detecting empty clusters
and removing them prior to the crossing logic. Fixes #1221.
fix: fclose(NULL) in the VRML plugin when current directory is not writable
The VRML plugin writes PNG files of each node in the graph alongside the VRML
output that then references these files. If you give no output location (do not
pass `-o` to dot), the VRML output is written to stdout and the node PNG files
are written to the current directory. However, the plugin was not checking
whether opening of these PNG files succeeded. As a result, if the current
directory was not writable, it would end up calling fclose() with a NULL
pointer.
This change makes the plugin report the failure to open PNG files and cause dot
to eventually exit with non-zero. Note that VRML processing is not stopped, so
the user can still get complete VRML output, albeit missing the associated PNG
files that will be referenced.
The test case included in this commit does not necessarily reproduce the failure
prior to these changes. This is because Glibc allows fclose(NULL). However, this
is beyond the spec and other libcs do not provide these guarantees.
projects / graphviz / log