-
Notifications
You must be signed in to change notification settings - Fork 13
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
Conversation
f6b8699
to
5ae9f7e
Compare
@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 |
thanks @rtorrero ! Not sure it will cause the same issue, as the cache for main branch as well would be regenerated. |
There was a problem hiding this 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?
lib/wanda/messaging/mapper.ex
Outdated
@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 |
There was a problem hiding this comment.
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?
@spec to_json(struct()) :: binary() | {:error, any()} | ||
def to_json(event) do |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
f98ba97
to
402a03b
Compare
402a03b
to
087c8d1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this 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?)
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