Hello, I want to archive all current launch plans for a workflow and register a new launch plan in CI/CD where I only know the current version (gitsha). How can I do this? Basically I would like

flytectl update launchplan ... -- version $GITSHA --activate >> --archive-old <<

. This seems like a basic use case but I have not found any resources on it. Please let me know if I overlooked anything

do you want to archive or simply deactivate all older launchplans?

Either, as long as they as deactivated

ya this is a common case, sorry for the delay in response

So a few points based on the example you gave me in DM… (related to your earlier question) * This definitely shouldn’t require two copies of the workflow. At worst it will require two different launch plans but not two workflows. Is your workflow running a different set of tasks between domains? Or just running the same task with different settings? * I think one way around this is just by setting an environment variable at compilation time (aka

pyflyte package/register

time) and detecting and loading different schedules. I feel like in the past though this hasn’t been a problem because typically users don’t run any schedules on any domain other than prod. And in those cases the activate command is simply omitted. * I notice that one of the fixed inputs is the s3 location. Just wanted to point out that the Flyte pointer types (flyteschema, structured dataset, and files/folders) already will write to the perhaps poorly named ‘raw output data prefix’ location. This setting is provided by Propeller to tasks at run time and is settable both on the launch plan level and as project/domain specific overrides. If no overrides are present, then Propeller will set a default. Regarding this question - is there a reason why you want to archive prior launch plans? You shouldn’t have to. For a given launch plan project/domain/name combination, only one version can be active at any time. Activating a new version will automatically deactivate the other versions. The archive process is our soft-delete, a tombstone marker if you will. This is fine, but it shouldn’t be necessary to do. Usually they’re not a distraction for our users because the drop-down list only shows the launch plans relevant to a specific version of a workflow, and users typically update the workflow version at the same time as the launch plan version. There’s also an related but kinda orthogonal issue here about altering behavior based on env vars, but we feel like this compromises the reproducibility of Flyte.