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

Serialize an ExecutionCompleted json cloud event #11

Merged
merged 5 commits into from
Aug 25, 2022

Conversation

nelsonkopliku
Copy link
Member

@nelsonkopliku nelsonkopliku commented Aug 23, 2022

This PR enables producing a json representation of trento.checks.v1.ExecutionCompleted as a cloud event.

It opens possibilities to support serialization for different events, yet I did not go too far considering that part of what is being done in wanda in relation to Cloud Events, would converge in trento contracts.

I had a bit of an issue with the cached dependencies, in this previous run for instance, where the schema was not found, while actually being there in the code.
I ended up adding the branch name (${GITHUB_REF##*/}) as part of the cache key used for the dependencies, which gave me updated deps and a green pipeline 😄
I understand it might slow down a bit because each branch would have its own cache, so reused only for subsequent runs of THAT branch and not cross-branch... at the same time I am wondering whether this might be actually helpful as it fixes cases like this 😅
What do you think? Suggestions?
opened #12 in this regard

@nelsonkopliku nelsonkopliku force-pushed the execution_completed_event branch 3 times, most recently from f6b8699 to 5ae9f7e Compare August 24, 2022 07:43
@nelsonkopliku nelsonkopliku marked this pull request as ready for review August 24, 2022 07:52
@nelsonkopliku nelsonkopliku changed the title Make Execution Result json encodable Serialize an ExecutionCompleted json cloud event Aug 24, 2022
@rtorrero
Copy link
Contributor

@nelsonkopliku great work!

About the CI problems: Does it really make sense to use the branch name as part of the key for the cache? Won't this cause trouble again when we merge it into main, as main didn't previously implement the schema either?

@nelsonkopliku
Copy link
Member Author

About the CI problems: Does it really make sense to use the branch name as part of the key for the cache? Won't this cause trouble again when we merge it into main, as main didn't previously implement the schema either?

thanks @rtorrero !

Not sure it will cause the same issue, as the cache for main branch as well would be regenerated.
What else am I missing? 🤔

Copy link
Contributor

@dottorblaster dottorblaster left a comment

Choose a reason for hiding this comment

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

Can we split this into a separate PR?

.github/workflows/ci.yaml Outdated Show resolved Hide resolved
lib/wanda/messaging/event_registry.ex Outdated Show resolved Hide resolved
lib/wanda/messaging/event_registry.ex Outdated Show resolved Hide resolved
Comment on lines 21 to 38
@spec to_json(struct()) :: binary() | {:error, any()}
def to_json(event) do
with {:ok, type, identifier} <- EventsRegistry.extract_metadata(event),
{:ok, cloud_event} <- build_cloud_event(identifier, type, event) do
Cloudevents.to_json(cloud_event)
end
end

defp build_cloud_event(id, type, event) do
%{
"specversion" => "1.0",
"id" => id,
"type" => type,
"source" => "https://github.com/trento-project/wanda",
"data" => event
}
|> CloudEvent.from_map()
end
Copy link
Contributor

Choose a reason for hiding this comment

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

My doubt is that we end up doing the exact same work in the contract repo, are we sure we wanna move forward with this?

Comment on lines +21 to +22
@spec to_json(struct()) :: binary() | {:error, any()}
def to_json(event) do
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think we need to return :ok or :error here, because conceptually nobody shouldn't be passing unsupported events to this function.

Copy link
Member Author

Choose a reason for hiding this comment

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

I am not sure I fully understand.
What do you mean? Could you elaborate a bit more?

Copy link
Contributor

Choose a reason for hiding this comment

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

The caller of this function should know if an event is supported or not, hence the tagged tuple is not needed here IMHO

Copy link
Contributor

@dottorblaster dottorblaster left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@dottorblaster dottorblaster left a comment

Choose a reason for hiding this comment

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

LGTM (wth is wrong with this UI?)

@nelsonkopliku nelsonkopliku merged commit 09862d4 into main Aug 25, 2022
@fabriziosestito fabriziosestito deleted the execution_completed_event branch November 17, 2022 17:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants