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 theCommitTimein thedsref.VersionInfoin place of aRunTimewhen we convert logs into version infos. This has been working fine from the view point of theActivityfeed, 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
Collectionview. Since theVersionInfoin theCollectionview 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 theCommitspecific fields alone.So that means in two different parts of our codebase, the
CommitTimefield can maybe be theRunTimeor theCommitTime, or is always theCommitTime.Frontend, similarly, has been using
CommitTimeto correctly mean theRunTimein theActivityLog,CommitTimein theDatasetHistory, and incorrectly meanRunTimein theCollectionI see two ways to solve: 1) add a
RunTimethat tracks the start of a run. We can use theRunTime+RunDurationif we need to track the run end time 2) rename theCommitTimefield toTime, and consider it theRunTimewhen there is aRunID, or theCommitTimewhen there is noRunID. I think this is dumb & we should definitely do the former.RunTimeto theVersionInfodefinitionrunItemFromOpinlogbookto pass the time into theRunTimefield, rather thanCommitTimeETLogbookWriteRunevent to pass therunState.StartTimeinWriteTransformRunCollectionto store theRunTimefrom theETLogbookWriteRuneventRunTimerecorded correctly & is not lost when other events write to theCollection