Hey, I just upgraded from prefect 2.0.0 to 2.0.4 and re-created my deployments. For one of my old deployments, I manually added a schedule-Definition and renamed the file to mydeployment_old.yaml. Then I ran prefect deployment build myflow.py:myflow --name mydeployment -t mytag -sb gcs/gcs-prefect-stprage -o mydeployment.yaml And like magic, the schedule definition block was automatically added to mydeployment.yaml. This is by the way awesome - but ... I don't know why this happened 😅 So, my question is I guess: How does prefect build know, which deployment-yaml settings to apply? Did it simply look in the mydeployment_old.yaml file which was in the same folder and figure "oh well, there is a schedule block in there, so I guess he'll need it in the new deployment as well"? (To get my intention right: This feature is awesome, I'd just like to understand how exactly it works, so that I can use it as intended)

haha Prefect 2.0 is all about the magic :wizard2: you can decide where to store and how to name the output YAML file by adding the -o flag (as you did) and then when you run apply, you explicitly decide which YAML manifest to use:

prefect deployment apply file1.yaml
# or:
prefect deployment apply file2.yaml

I had a similar situation the other day except I didn't have an "old" deployment file! My hypothesis is that the deployment build command will actually read certain settings from the server and inject them back into the generated yaml. This is likely done so that schedules defined in the GUI will be kept when you re-deploy the uh, deployment. Does that make sense?

btw if you look at the main branch, we added --cron, --interval and --rrule flags to the build CLI, so you can now even define schedule from CLI - will likely get released today or later this week

@Anna Geller :wizard2: 😂 But why did my newly created deployment already had a schedule definition in the yaml file? I swear I did not add it there manually and I also did not use the interval/cron flags. So prefect somehow needs to extract the schedule information from my old deployment-file?

the right way to treat YAML is as a build artifact confirming what data will be sent to the API call for apply step

Ahhh! Awesome! Thanks!!