Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gerrit-translator-cdevents : Plugin implementation to translate branch and repository events #1

Merged
merged 6 commits into from
Jul 3, 2024

Conversation

rjalander
Copy link
Contributor

@rjalander rjalander commented Mar 19, 2024

Implementation of EventTranslator interface that is exposed by CDEvents Webhook Adapter to translate gerrit events into CDEvents.
This PR includes the changes to translate below Project and Branch related gerrit events into CDEvents, with the mappings as below

CDEvent Type Gerrit Event Type
dev.cdevents.repository.created project-created
dev.cdevents.repository.modified project-head-updated
dev.cdevents.branch.created ref-updated
dev.cdevents.branch.deleted ref-updated

Note: Implementation as per the design RFC: gerrit-translator-cdevents-plugin and mapping events gerrit-cdevents

Signed-off-by: Jalander Ramagiri @rjalander

Signed-off-by: Jalander Ramagiri <jalander.ramagiri@est.tech>
@rjalander rjalander requested review from adamkenihan and removed request for adamkenihan March 20, 2024 15:51
Signed-off-by: Jalander Ramagiri <jalander.ramagiri@est.tech>
Copy link

@xibz xibz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rjalander This looks like a good start. I have some questions and some ideas on how to make this a little more scalable.

README.md Outdated Show resolved Hide resolved
cdEvent, err := sdk.NewRepositoryCreatedEvent()
if err != nil {
log.Printf("Error creating CDEvent RepositoryCreatedEvent %s\n", err)
return "", err
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing that might be appropriate to do is wrap these in our own Error. I think a little digging is required here, but what do the errors look like when returned from the SDK?

For instance, if the error that is returned is something like error: pipe broken than that's not too useful. Wrapping these errors with something that provides more context may be necessary

Right now we have two repos:

The plugin webhook adapter thingy and translator(s).

The webhook adapter can provide a set of Error types that can be wrapped, and I think that would at least give some guidance on how the adapter should handle such errors, e.g. should we return a proper status code based on error type for example.

This will require some design, but I think it's an important call out and consideration.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will create an issue for handling these error scenarios and discuss design considerations here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rjalander could you share a link to the issue?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pkg/gerrit/create_cdevents.go Outdated Show resolved Hide resolved
return cdEventStr, nil
}

func (projectHeadUpdated *ProjectHeadUpdated) RepositoryModifiedCDEvent() (string, error) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this seems a little odd, and I was thinking of a much different approach. Can you schedule a meeting with me? I want to go over some design consideration here

Signed-off-by: Jalander Ramagiri <jalander.ramagiri@est.tech>
@rjalander rjalander requested a review from xibz April 26, 2024 12:34
Signed-off-by: Jalander Ramagiri <jalander.ramagiri@est.tech>
xibz
xibz previously approved these changes May 1, 2024
Copy link

@xibz xibz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had just two comments, but I think we still need to go over the implementation of the go tags. It'll make this much easier in the future. Can you schedule something for this week?

.github/workflows/ci.yml Show resolved Hide resolved
pkg/gerrit/logger.go Outdated Show resolved Hide resolved
@xibz xibz dismissed their stale review May 1, 2024 01:41

wrong click

Copy link

@xibz xibz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

requesting some changes

Signed-off-by: Jalander Ramagiri <jalander.ramagiri@est.tech>
Copy link

@xibz xibz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just adding a comment about our prior meeting with Jalander and Andrew.

The goal is to utilize copygen or some library that supports easy copying of structs without needing to manually write them ourselves.

There was some concerns around perfection and feature creep, so we decided that if we are unable to get struct tags in the go sdk by mid July, we will go ahead with the duplicated copying logic until struct tags exist.

@rjalander
Copy link
Contributor Author

Just adding a comment about our prior meeting with Jalander and Andrew.

The goal is to utilize copygen or some library that supports easy copying of structs without needing to manually write them ourselves.

There was some concerns around perfection and feature creep, so we decided that if we are unable to get struct tags in the go sdk by mid July, we will go ahead with the duplicated copying logic until struct tags exist.

created this PR cdevents/sdk-go#82 to support copygen for go-sdk

Copy link

@xibz xibz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for all the changes @rjalander. I will go ahead and approve this. The goal, however, is to eventually use some copier library to make it easy for translators to be developed. I will create a separate issue for that.

@rjalander
Copy link
Contributor Author

Thanks for all the changes @rjalander. I will go ahead and approve this. The goal, however, is to eventually use some copier library to make it easy for translators to be developed. I will create a separate issue for that.

Thanks @xibz, We will address this issue and initiate a separate pull request to implement the copying of metadata utilizing a designated copier library.

@afrittoli, could you please review this PR and approve it if there are no comments?

README.md Outdated Show resolved Hide resolved
Copy link
Contributor

@afrittoli afrittoli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing that I noticed is that the plugin here returns CDEvents as JSON.

Currently the AsCloudEvent function takes a CDEvent reader object as input, and there is no obvious way to send a JSON CDEvent as CloudEvent other than parsing it back into an object and using AsCloudEvent.

Perhaps we'll need a new method in the SDK. or a different interface here

go.mod Show resolved Hide resolved
@rjalander
Copy link
Contributor Author

One thing that I noticed is that the plugin here returns CDEvents as JSON.

Currently the AsCloudEvent function takes a CDEvent reader object as input, and there is no obvious way to send a JSON CDEvent as CloudEvent other than parsing it back into an object and using AsCloudEvent.

Perhaps we'll need a new method in the SDK. or a different interface here

I tried using an interface which accepts cdevent object as a returned value instead of cdevent JSON string in the webhook-adapter, but that has some difficulties in generating grpc client code using protoc-gen for custom datatypes.
So using JSON string as a response for this interface, https://github.com/cdevents/webhook-adapter/blob/main/pkg/proto/translator.proto#L37

And in webhook-adapter the received cdevent JSON string will be converted to cdevent object using NewFromJsonString(event string) (CDEvent, error), but looks like this method is replaced in the main go-sdk (need to use differently once webhook-adapter upgraded to v0.4 sdk)

Signed-off-by: Jalander Ramagiri <jalander.ramagiri@est.tech>
@afrittoli
Copy link
Contributor

One thing that I noticed is that the plugin here returns CDEvents as JSON.
Currently the AsCloudEvent function takes a CDEvent reader object as input, and there is no obvious way to send a JSON CDEvent as CloudEvent other than parsing it back into an object and using AsCloudEvent.
Perhaps we'll need a new method in the SDK. or a different interface here

I tried using an interface which accepts cdevent object as a returned value instead of cdevent JSON string in the webhook-adapter, but that has some difficulties in generating grpc client code using protoc-gen for custom datatypes. So using JSON string as a response for this interface, https://github.com/cdevents/webhook-adapter/blob/main/pkg/proto/translator.proto#L37

And in webhook-adapter the received cdevent JSON string will be converted to cdevent object using NewFromJsonString(event string) (CDEvent, error), but looks like this method is replaced in the main go-sdk (need to use differently once webhook-adapter upgraded to v0.4 sdk)

I could not avoid having the NewFromJsonString method being version specific - so in the new SDK you have one version for v0.3 and one for v0.4.

There is a NewFromJsonBytes method that works with golang generics and can be used across spec versions, but the version specific NewFromJsonString is more convenient to use.

@rjalander
Copy link
Contributor Author

One thing that I noticed is that the plugin here returns CDEvents as JSON.
Currently the AsCloudEvent function takes a CDEvent reader object as input, and there is no obvious way to send a JSON CDEvent as CloudEvent other than parsing it back into an object and using AsCloudEvent.
Perhaps we'll need a new method in the SDK. or a different interface here

I tried using an interface which accepts cdevent object as a returned value instead of cdevent JSON string in the webhook-adapter, but that has some difficulties in generating grpc client code using protoc-gen for custom datatypes. So using JSON string as a response for this interface, https://github.com/cdevents/webhook-adapter/blob/main/pkg/proto/translator.proto#L37
And in webhook-adapter the received cdevent JSON string will be converted to cdevent object using NewFromJsonString(event string) (CDEvent, error), but looks like this method is replaced in the main go-sdk (need to use differently once webhook-adapter upgraded to v0.4 sdk)

I could not avoid having the NewFromJsonString method being version specific - so in the new SDK you have one version for v0.3 and one for v0.4.

There is a NewFromJsonBytes method that works with golang generics and can be used across spec versions, but the version specific NewFromJsonString is more convenient to use.

Ok, will use the same function NewFromJsonString after webhook-adaper is upgraded to v0.4

@rjalander
Copy link
Contributor Author

@afrittoli, could you please approve it if there are no other comments?

@afrittoli afrittoli merged commit 5b5569b into cdevents:main Jul 3, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants