add skipRange support to render-graph

[grokspawn]

Signed-off-by: Jordan Keister jordan@nimblewidget.com

Description of the change:
mermaid output of channels will express skipRange relationships between nodes

Motivation for the change:
tired of the header/footer always expressing the feature's shortcomings ;)

Reviewer Checklist

• Implementation matches the proposed design, or proposal is updated to match implementation
• Sufficient unit test coverage
• Sufficient end-to-end test coverage
• Docs updated or added to /docs
• Commit messages sensible and descriptive

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: grokspawn

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [grokspawn]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[cdjohnson]

Thanks for doing this. I tried it out against one our packages: ibm-mq.

Question: This clearly shows the graph between bundles. Is there any thought of showing the upgrade graphs between channels, so one can see the intra-channel upgrade paths a bit more obviously?

Maybe it would be a different render command, or it would get too busy?

E.g. Make it obvious that you can move from any channel to the v2.0 channel. We have other examples, where one needs to traverse from v1.0 to v1.1 to v2.0 and directly from v1.0 to v2.0.

Here's what the ibm-mq one looks like:

[codecov]

Codecov Report

Merging #1022 (fff97c1) into master (a3c883e) will increase coverage by 0.16%.
The diff coverage is 52.63%.

@@            Coverage Diff             @@
##           master    #1022      +/-   ##
==========================================
+ Coverage   51.68%   51.84%   +0.16%     
==========================================
  Files         102      102              
  Lines        9164     9181      +17     
==========================================
+ Hits         4736     4760      +24     
+ Misses       3520     3509      -11     
- Partials      908      912       +4     

Impacted Files	Coverage Δ
alpha/declcfg/write.go	73.91% <52.63%> (+8.63%)	⬆️
alpha/veneer/semver/semver.go	60.00% <0.00%> (-0.50%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[grokspawn]

I'm abandoning this PR in favor of #1023. There started to be complex interactions between the different filtering options, and an increasing burden of sequencing the PRs was just more than I wanted to countenance.
I'll read through the feedback so far and see what I can incorporate... I'm not ignoring it. It's just that I had to consolidate to reduce complexity.

[grokspawn]

Thanks for doing this. I tried it out against one our packages: ibm-mq.

Question: This clearly shows the graph between bundles. Is there any thought of showing the upgrade graphs between channels, so one can see the intra-channel upgrade paths a bit more obviously?

Maybe it would be a different render command, or it would get too busy?

E.g. Make it obvious that you can move from any channel to the v2.0 channel. We have other examples, where one needs to traverse from v1.0 to v1.1 to v2.0 and directly from v1.0 to v2.0.

Here's what the ibm-mq one looks like:

That is really cool!

I hadn't really ever thought about inter-channel linkages before, honestly. It would definitely make the graph more noisy. I'll give it a look.

[bentito]

The CNV folks have expressed a desire for inter-index graphs as well. That is, it would show the way to proceed when you move to another index.