@Marvin Is it possible to pass a parameter to a Deployment? Is yes, how?

@Marvin Is it possible to pass a parameter to a Deployment? Is yes, how?

Yes, it is possible to pass parameters to a Deployment in Prefect 2.x. To create an ad-hoc flow run with different parameter values for an existing deployment, you can perform the following steps: 1. Go to the details page for the deployment. 2. Select Run. 3. Choose Custom to provide custom values for any editable deployment fields. 4. Under Parameters, select Custom. 5. Provide the new parameter values. 6. Select Save. 7. Choose Run to begin the flow run with the custom values. For deployments created using a

deployment.yaml

file, you can edit the file to set the default parameter values before applying the deployment using the

prefect deployment apply

command. However, be cautious not to edit the section of the YAML file that includes the "DO NOT EDIT" comment, as that part is autogenerated and should not be manually changed. If you want the Prefect API to enforce the parameter schema, you can set

enforce_parameter_schema

to

true

to ensure that the parameter values passed to a flow run are verified against the schema defined by the

parameter_openapi_schema

. You can read more about this in the Prefect documentation: Deployments.

hmm the stuff about creating it in the UI is fine, but marvin should have discussed the

prefect.yaml

instead of

deployment.yaml

. you can also pass params to an adhoc deployment run with

run_deployment(..., parameters={...{})

@Nate: I've been working on creating an YAML file that defines the trigger for an automation. And in the

actions

section,

run-deployment

is the only action that related closely to running a flow. Is there something specific to flow? like

run-flow

? Or does this apply for flows too? If the latter is the case, can I mention the

flow-id

as

deployment-id

?

in order to trigger a flow run as the action of an automation, you must elevate that flow to a deployment and then yeah, use the Run a Deployment action. feel free to share your trigger definition if you’re wanting to do that and having trouble

Context: I have an

archiving

flow elevated to deployment. But, I have multiple flows that will resuse this deployement by changing the

path

. In case of Deployment how do I pass the dynamic path parameter via the automation?

at this time, a deployment is 1:1 with the path where that deployment lives. you could however have a parent deployment that calls the appropriate subflow based on the path. you could trigger the parent deployment as the action of your automation

Clarification:

path

refers to a variable that contains the path to the files the needs to be archived. I need to pass this dynamic

path

variable to a deployment via automation triggers. I hope this clarifies.

aha i see, thought you meant the deployment path. you’d wanna emit your path in the payload of the event, then you can template that into your parameters in your deployment trigger definition in prefect.yaml @Marvin example pls

To template parameters in your deployment trigger definition within

prefect.yaml

, you would include triggers with templated parameters that can extract values from events. Here is an example of how you can set this up: Suppose you have a YAML configuration file named

prefect.yaml

for your deployment trigger. You would include a section that looks something like this:

yaml
flow.py:decorated_fn
work_pool:
  name: my-process-pool
triggers:
  - enabled: true
    match:
      prefect.resource.id: my.external.resource
    expect:
      - external.resource.pinged
    parameters:
      param_1: "{{ event }}"

In this example: - `enabled`: This should be set to

true

to enable the trigger. - `match`: A dictionary specifying the matching criteria for the events that should trigger the automation.

prefect.resource.id

is compared with the event source identifier. - `expect`: A list of event types that this trigger expects to react to, such as

'external.resource.pinged'

. - `parameters`: A dictionary where the keys correspond to the parameter names expected by the flow, and the values are templated to contain the event payload. At deployment time, this configuration will create a linked automation that is triggered by events matching your chosen criteria and will pass the templated event as a parameter to the deployment's flow run. You can also provide triggers from the CLI when deploying, for example:

bash
prefect deploy -n test-deployment --trigger triggers.yaml

This command references an external

triggers.yaml

file, which can house multiple trigger definitions. Suppose the

triggers.yaml

file looks like this:

yaml
triggers:
  - enabled: true
    match:
      prefect.resource.id: my.external.resource
    expect:
      - external.resource.pinged
    parameters:
      param_1: "{{ event }}"
  - enabled: true
    match:
      prefect.resource.id: my.other.external.resource
    expect:
      - some.other.event
    parameters:
      param_1: "{{ event }}"

This approach allows the definition of multiple triggers within the same file, each with potentially different match and expect criteria, and unique parameter templating based on the incoming event data. For more information on automatons and triggers, you can visit the Prefect documentation on Automations.

@Nate One last question: We're currently on Prefect version 2.13.1, can we implement emit_event?

emit_event should already be around, from prefect.events import emit_event

The emit_event method must be within the flow that triggers the archiving flow/deployment?

yeah like oftentimes you'll do something like this

Thank you so sooo much!!!

In the example provided by marvin, does the

param_1

point towards the name of the event?

thats like the whole event, this is jinja so you can do dot access on that, @Marvin example pls

In Prefect 2.x, when using Jinja to template event properties in triggers, you have the ability to access specific properties of an event object. When the event is a JSON object, you can use either index or attribute access to get the values you need. Here is an example of how you can access specific properties from an event in your trigger definitions:

yaml
triggers:
  - enabled: true
    match:
      prefect.resource.id: my.external.resource
    expect:
      - external.resource.pinged
    parameters:
      # Accessing a top-level property from the event
      param_top_level: "{{ event.property_name }}"
      # Accessing a nested property from the event
      param_nested: "{{ event.nested.property_name }}"

This example illustrates two ways to access the event data: 1. `param_top_level`: Accesses a top-level property of the event. Replace

property_name

with the actual name of the property in the event you want to access. 2. `param_nested`: Accesses a nested property of the event. Replace

nested.property_name

with the actual path to the nested property from the event you want to access. It is important to note that when using attribute-style access (

event.property_name

), it only works if the event property is a valid Python identifier. If the property name includes characters that are not valid in Python identifiers (like hyphens), you should use the index-style access (

event['property-name']

). For more complex scenarios, you can use the full power of Jinja templating within Prefect to manipulate the event data as needed for passing it as parameters to your flows. For additional details on how to use webhooks and Jinja templates in Prefect, you can check out the Prefect documentation on Webhooks.