tetragon: create api go module for tooling #231
Conversation
Working on tooling and event handlers, such as hubble, its a bit ugly to pull in the entire go mod when the user simply wants the API definitions. Further, its useful to version the API so we can all agree on what version is in use. Allowing us to fix core code easily and keep the API side consistent from a versioning perspective. To facilitate this create go module out of API code. Signed-off-by: John Fastabend <[email protected]>
jrfastab
force-pushed
the
pr/jrfastab/gomod-api
branch
3 times, most recently
from
996f4ed to
3a88ca7
Compare
The check module vendoring currently just reports an error, but does not give any information about what the error is. This adds an echo to print the status output so user can see what the problem is from the action logs. This helps in the current case I'm dealing with where it doesn't reproduce locally for some reason. Signed-off-by: John Fastabend <[email protected]>
jrfastab
force-pushed
the
pr/jrfastab/gomod-api
branch
from
d4a1051 to
ea90271
Compare
There was a problem hiding this comment.
LGTM. I just had one question and one suggestion.
Question: Will vendoring API inside of tetragon and tetragon inside of API ever create a dependency cycle in the future? I would suggest maybe having pkg/matchers be its own module or moving pkg/matchers into API to avoid this.
Suggestion: We should consider moving cmd/protoc-gen-go-tetragon into the API module to cleanly separate concerns between the two modules. It made sense to have it live in cmd/ when they were all one module but IMO not so much anymore.
I don't think either of the above points are worth blocking this on so I'll just ACK for now.
|
the cycle doesn't block anything at the moment but does sound like it could be annoying to manage from a vendoring perspective. Anyways the pkg/matchers should just be pulled into api/ which makes it clean and then vendor is much nicer. |
Working on tooling and event handlers, such as hubble, its a bit ugly
to pull in the entire go mod when the user simply wants the API
definitions. Further, its useful to version the API so we can all
agree on what version is in use. Allowing us to fix core code easily
and keep the API side consistent from a versioning perspective.
To facilitate this create go module out of API code.