Add context to triggers/automations #5758
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The focus of this PR is to get the automation triggers from Prefect working again in the
develop
branch. This is done by ensuring that we send the now requiredInfrahubContext
object in different formats depending on if it's a trigger setup within Prefect (then we send it as JSON payload from the event.payload['context'] data and convert it into a dictionary instead of sending it as a string. The alternative is when se just submit or execute a workflow and send the context object as is.The InfrahubContext object has been added as a required object to the event Metadata field. There are a few things to note about this:
Because we always want to send the InfrahubContext as part of the event payload I added a new .get_event_payload() method that should only be defined on the root InfrahubEvent object and then child classes can override the get_payload() method without having to worry about the requirement to include the "context" key.
I added a new test to infrahub_docker where we validate that the trigger for the computed attribute (for Jinja) is working. So now we at least won't run into the same situation again. Those tests should be expanded on upcoming PRs though to also run the same type of tests for the Python Transform based computed attributes as well as testing the computed attributes on different branches.
I also enabled a test that was previously disabled. I'm not sure why it was failing before or if it started to work after the recent changes to the InfrahubEvent GraphQL query.