-
Notifications
You must be signed in to change notification settings - Fork 14
WIP: execution replay #299
base: main
Are you sure you want to change the base?
Conversation
d439a16
to
7c85a28
Compare
How to test:
|
Codecov Report
@@ Coverage Diff @@
## master #299 +/- ##
==========================================
+ Coverage 91.38% 93.51% +2.13%
==========================================
Files 31 46 +15
Lines 1137 1742 +605
Branches 106 127 +21
==========================================
+ Hits 1039 1629 +590
- Misses 98 113 +15
Continue to review full report at Codecov.
|
@tfenne I am very close to having replay supported in the "old" execsystem, but I am running out of time for today! |
No tests for replay but it works in my hands for both execution systems! |
561451c
to
de947d5
Compare
@tfenne I now have test coverage across all the code I want. I was thinking we could do a multi-stage review if you are up for it? I see three main sections:
Probably the order should be 3, 2, 1. It may be hard to do each entirely separately, but I think it should be possible with only a minimal look at the others while reviewing one. Thoughts on how to proceed? |
@@ -95,7 +95,7 @@ lazy val commonSettings = Seq( | |||
testOptions in Test += Tests.Argument(TestFrameworks.ScalaTest, "-h", Option(System.getenv("TEST_HTML_REPORTS")).getOrElse(htmlReportsDirectory)), | |||
testOptions in Test += Tests.Argument("-l", "LongRunningTest"), // ignores long running tests | |||
// uncomment for full stack traces | |||
//testOptions in Test += Tests.Argument("-oD"), | |||
testOptions in Test += Tests.Argument("-oDF"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: comment me
build.sbt
Outdated
@@ -123,6 +123,7 @@ lazy val core = Project(id="dagr-core", base=file("core")) | |||
"com.fulcrumgenomics" %% "commons" % "0.2.0-SNAPSHOT", | |||
"com.fulcrumgenomics" %% "sopt" % "0.2.0-SNAPSHOT", | |||
"com.github.dblock" % "oshi-core" % "3.3", | |||
"com.beachape" %% "enumeratum" % "1.5.12", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: tabs -> spaces
case class Definition(simpleName: String, name: String, code: Int, parentCode: Int, childNumber: Int) extends ToStringIsSimpleNameUpperCase { | ||
/** Returns true if the the other definition represents the same task as the this definition. Assumes that | ||
* the parents have the same number of child tasks. */ | ||
def equivalent(that: Definition): Boolean = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tfenne this is the where we determine two tasks are "equivalent" across executions. You'll likely find that it is too conservative, so any ideas would be helpful.
val equivalentChildren = currentChildDefinitions.exists { left => | ||
currentChildDefinitions.exists { right => left != right && left.equivalent(right) } | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tfenne this is the where we determine if a pipeline-like task (a task that returns other tasks) is equivalent across executions. We look for:
- The task must produce the same # of children.
- None of the children produced are "equivalent" to each other (i.e. one cannot be misinterpreted for the other across executions).
- Each child has one and only one equivalent "definition" from the previous execution, meaning for each child task we found one and only one potential matching task from the previous execution.
If the above are true, we evaluate whether or not to run the children separately (by their previous status), otherwise, we force all the children to run.
} | ||
Logger.out = tmpOut | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: add a test of a pipeline within a pipeline within a pipeline, such that the middle-level pipeline produces different pipelines on the second execution, and so the middle and bottom level pipelines are forced to execute.
Refactor task and exec system prior to new execution system.
This system can be used with the --experimental-execution option.
Outline of tests for TaskCache
No description provided.