feat: add constructor for full event lineage graph

[Cali0707]

Fixes #7694

Proposed Changes

• Get resources from cluster and construct a graph

[Cali0707]

/cc @pierDipi

[knative-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Cali0707

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 [Cali0707]

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

[Cali0707]

This is WIP because I want feedback on the approach before adding unit tests

[codecov]

Codecov Report

Attention: Patch coverage is 9.67742% with 224 lines in your changes missing coverage. Please review.

Project coverage is 67.04%. Comparing base (2cc0a5b) to head (d60a069).
Report is 47 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/graph/constructor.go	10.90%	196 Missing ⚠️
pkg/graph/types.go	0.00%	28 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7921      +/-   ##
==========================================
- Coverage   67.87%   67.04%   -0.83%     
==========================================
  Files         368      368              
  Lines       17551    17777     +226     
==========================================
+ Hits        11912    11918       +6     
- Misses       4894     5113     +219     
- Partials      745      746       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Cali0707]

/cc @pierDipi @aliok

[aliok]

Can we actually embed the full broker resource in the graph here? Or make it a config option?

Because, for example in the Backstage backend, if I only have references, I will need to fetch the brokers again. But, we have the full resource here fetched anyway.

[aliok]

@Cali0707 this is done, right?

[Cali0707]

Yes, the resources are all added with type interface{} to each vertex

[aliok]

Kind of irrelevant for this PR, but it would be super nice if we have a stringer for graph and vertices for debugging purposes. A text like

A (broker.eventing.knative.dev) --> B (foo.bar)
...etc

[Cali0707]

/cc @aliok
Thanks for all the feedback!!

[Cali0707]

Kind of irrelevant for this PR, but it would be super nice if we have a stringer for graph and vertices for debugging purposes. A text like

A (broker.eventing.knative.dev) --> B (foo.bar)
...etc

Yeah 100%, I thought about this too but I wasn't sure how to show a vertex with an arbitrary number of edges using just strings...

[aliok]

Yeah 100%, I thought about this too but I wasn't sure how to show a vertex with an arbitrary number of edges using just strings...

I added stringer impls for types now. It is ok-ish. Example:

Kind = Broker, Namespace = default, Name = test-broker, APIVersion = eventing.knative.dev/v1, Group = , Address = 
Kind = Broker, Namespace = default, Name = default, APIVersion = eventing.knative.dev/v1, Group = , Address = 
Kind = EventType, Namespace = default, Name = test-event-type, APIVersion = eventing.knative.dev/v1beta3, Group = , Address = 
Out Edges:
        [Kind = EventType, Namespace = default, Name = test-event-type, APIVersion = eventing.knative.dev/v1beta3, Group = , Address = ] --> [Kind = Broker, Namespace = default, Name = test-broker, APIVersion = eventing.knative.dev/v1, Group = , Address = ]

[aliok]

@Cali0707

Say we have an EventType:

kind: EventType
metadata:
  name: test-event-type
  namespace: default
spec:
  reference:
    apiVersion: eventing.knative.dev/v1
    kind: Broker
    name: test-broker

Currently the graph is constructed in a way that there is an edge from ET to Broker.

I think it should be the other way around.

Events of EventType is coming out of broker.

cc @pierDipi

[Cali0707]

@aliok @pierDipi is there anything left for this PR? Should we merge this and move to some follow up issues/PRs for anything that comes up?

[Cali0707]

@aliok do you think we can merge this PR and then make any required changes on follow up PRs?

[aliok]

/test reconciler-tests

[aliok]

I think we can merge this one.

I can make changes later on

[aliok]

/test reconciler-tests

[Cali0707]

/retest-required

[Cali0707]

/cc @aliok @pierDipi @creydr can we move forwards with this PR?

[aliok]

/lgtm
/hold

Holding for others to review if necessary

[pierDipi]

/unhold