In logbook, we are currently using the CommitTime in the dsref.VersionInfo in place of a RunTime when we convert logs into version infos. This has been working fine from the view point of the Activity feed, because each version info is only there to describe a single run or a single commit, not the dataset as a whole. So based on whether or not a version info has a RunID (in this context), you can determine whether or not we are talking about a "run" activity or a "commit" activity.
However, this is muddied in the Collection view. Since the VersionInfo in the Collection view models the entire dataset as a whole, we have it structured that a user may have commit information from one run as well as run information about another run in the same version.
For example. If we run a workflow that successfully produces a commit, we catch that information in the Collection, which updates the RunID, RunDuration, RunCount, RunStatus, CommitCount, CommitTitle, CommitMessage, Path, and CommitTime.
Next, we run a workflow which runs successfully, but does not produce a commit (no changes). The collection will update the RunID, RunDuration, RunCount, and RunStatus, but leave the Commit specific fields alone.
So that means in two different parts of our codebase, the CommitTime field can maybe be the RunTime or the CommitTime, or is always the CommitTime.
Frontend, similarly, has been using CommitTime to correctly mean the RunTime in the ActivityLog, CommitTime in the DatasetHistory, and incorrectly mean RunTime in the Collection
I see two ways to solve:
1) add a RunTime that tracks the start of a run. We can use the RunTime + RunDuration if we need to track the run end time
2) rename the CommitTime field to Time, and consider it the RunTime when there is a RunID, or the CommitTime when there is no RunID. I think this is dumb & we should definitely do the former.
[x] add RunTime to the VersionInfo definition
[x] adjust runItemFromOp in logbook to pass the time into the RunTime field, rather than CommitTime
[x] adjust the ETLogbookWriteRun event to pass the runState.StartTime in WriteTransformRun
[x] adjust the Collection to store the RunTime from the ETLogbookWriteRun event
[x] update tests ensuring the RunTime recorded correctly & is not lost when other events write to the Collection
In
logbook
, we are currently using theCommitTime
in thedsref.VersionInfo
in place of aRunTime
when we convert logs into version infos. This has been working fine from the view point of theActivity
feed, because each version info is only there to describe a single run or a single commit, not the dataset as a whole. So based on whether or not a version info has aRunID
(in this context), you can determine whether or not we are talking about a "run" activity or a "commit" activity.However, this is muddied in the
Collection
view. Since theVersionInfo
in theCollection
view models the entire dataset as a whole, we have it structured that a user may have commit information from one run as well as run information about another run in the same version.For example. If we run a workflow that successfully produces a commit, we catch that information in the
Collection
, which updates theRunID
,RunDuration
,RunCount
,RunStatus
,CommitCount
,CommitTitle
,CommitMessage
,Path
, andCommitTime
.Next, we run a workflow which runs successfully, but does not produce a commit (no changes). The collection will update the
RunID
,RunDuration
,RunCount
, andRunStatus
, but leave theCommit
specific fields alone.So that means in two different parts of our codebase, the
CommitTime
field can maybe be theRunTime
or theCommitTime
, or is always theCommitTime
.Frontend, similarly, has been using
CommitTime
to correctly mean theRunTime
in theActivityLog
,CommitTime
in theDatasetHistory
, and incorrectly meanRunTime
in theCollection
I see two ways to solve: 1) add a
RunTime
that tracks the start of a run. We can use theRunTime
+RunDuration
if we need to track the run end time 2) rename theCommitTime
field toTime
, and consider it theRunTime
when there is aRunID
, or theCommitTime
when there is noRunID
. I think this is dumb & we should definitely do the former.RunTime
to theVersionInfo
definitionrunItemFromOp
inlogbook
to pass the time into theRunTime
field, rather thanCommitTime
ETLogbookWriteRun
event to pass therunState.StartTime
inWriteTransformRun
Collection
to store theRunTime
from theETLogbookWriteRun
eventRunTime
recorded correctly & is not lost when other events write to theCollection