I have

prefect-server

and

prefect-worker

deployed to my local cluster.

that path is relative to the current working directory, so if your code is in an image, and that image's starting dir doesn't match your deployment's entrypoint, you can use the pull step to set the working dir

if your deployment is grabbing code from elsewhere, like a git repo or a bucket, you'll need to specify that in the pull step. Having an image for dependency management but actual flow code in a repo or some other remote storage is a common setup since it means you don't have to rebuild your image every time your code changes. In this case the pull step will clone the repo or otherwise copy down your remote code files before attempting to find and execute the deployment's entrypoint

I''d like to avoid injecting code into an image that might not have the right dependencies. I'm not sure that's a great approach. That's one of the reasons I am using Pants, so that I can make reproducible fast builds in a monorepo.

I would recommend creating a work pool of the type you need, then going to the thee dots -> edit -> advanced just to make the mental connection between what the template does and how the variable names are used in a deployment's

job_variables

Hey @Kevin Grismore. I got it all working with Workers, and now it all seems pretty straightforward. I found it pretty confusing in the docks between what is referring to worker type deployments and agent type deployments, and finding complete specs without having to go into the UI and look through the json, and understand how parts of that related to parts of the prefect file. One thing I got really confused about was actually deploying the

prefect.yaml

file. When you look at

prefect deployment apply --help

it refers to a deployment yaml file. This I learnt is not anything to do with the deployment I wanted to deploy. Instead it was

prefect --no-prompt deploy --name example

I was looking for, which doesn't say anything about running against the

prefect.yaml

file, so it was all a bit magic. It's also pretty counter intuitive to have to supply an

entrypoint

when that isn't even an input to the standard kubernetes job template. It's a little bit annoying to have put something valid to get it to run, but mostly a little misleading IMO. I hope you like getting feedback, in general I am liking a lot about the framework, and it feels like it's moving in the right direction. This is what I ended up with, which I would have struggled to achieve with out your help, so big thanks!

name: flows
prefect-version: 2.13.8
build:
push:
pull:

deployments:
- name: example
  schedule:
  work_pool:
    name: development
    job_variables:
      image: prefect-example:latest
      namespace: prefect-worker
      image_pull_policy: Never
    work_queue_name:
  entrypoint: src/examples/flow/__main__.py:get_repo_info
  version:
  tags: []
  description:
  parameters: {}

Just a final thought. Pretty much all my pain points are in the guide, but perhaps the guides could be a little more step by step hello world like.

I know I often say "yaml-based deployments" when talking about

prefect.yaml

but that's not entirely clear without more specificity.