dagster
dagster copied to clipboard
[DS][28/n] Create WillBeRequestedCondition
Summary & Motivation
Creates a WillBeRequestedCondition. Naming is somewhat sketch, but the basic idea is that in the past we've merged together this concept with existing rules.
I.e. in AMP-world, the "skip_on_parent_missing" rule is actually "skip on parent (missing and will not be requested this tick)".
This is obviously a bit confusing, and now that all of our dep conditions are composable, breaking this out into its own separate condition is desirable.
How I Tested These Changes
-
#21641
: 2 dependent PRs (#21670
, #21671
)
-
#21640
👈
-
#21648
-
#21615
-
#21613
-
#21612
-
#21573
-
#21546
-
#21545
-
#21541
-
#21540
-
#21539
-
#21538
-
#21537
-
#21536
-
#21535
-
#21521
-
#21520
-
#21511
: 1 other dependent PR (#21512
)
-
#21510
-
#21508
-
#21507
-
#21505
-
#21504
-
#21503
-
#21502
-
#21501
-
#21500
-
#21499
-
master
This stack of pull requests is managed by Graphite. Learn more about stacking.
Join @OwenKephart and the rest of your teammates on Graphite
Could you add a condition that instead of only working on any or all assets, it applies to an explicit subset?
@ion-elgreco
Could you add a condition that instead of only working on any or all assets, it applies to an explicit subset?
Adding that functionality to SchedulingCondition.any_deps_match
and similar is certainly in the plans -- currently conceptualizing adding allow_keys
and ignore_keys
type arguments.