We already have a runID field on the commit in the backend, we just needed to surface it on the frontend!
Also closes the frontend portion of #576
Some notes:
a bunch of these refactors are to get LogItem in line with VersionInfo, which is the actual data structure that come back from the backend. I think with these changes we can mostly get rid of any references to LogItem in favor of using VersionInfo, but wanted to make a note of the changes and not do the entire refactor in one sweep, which can be jarring if everyone working on the code base isn't made aware of the change before it happens.
Why should we refactor away from LogItem? For long term maintenance, its easier to work with as few data models as possible. Since VersionInfo is the actual data structure coming from the backend, and it is exactly the same as the LogItem, it will be easier for us in the long term to slim down to using just one, and only create a separate data structure when we absolutely need it.
closes #430
We already have a
runIDfield on thecommitin the backend, we just needed to surface it on the frontend!Also closes the frontend portion of #576
Some notes:
a bunch of these refactors are to get
LogItemin line withVersionInfo, which is the actual data structure that come back from the backend. I think with these changes we can mostly get rid of any references toLogItemin favor of usingVersionInfo, but wanted to make a note of the changes and not do the entire refactor in one sweep, which can be jarring if everyone working on the code base isn't made aware of the change before it happens.Why should we refactor away from
LogItem? For long term maintenance, its easier to work with as few data models as possible. SinceVersionInfois the actual data structure coming from the backend, and it is exactly the same as theLogItem, it will be easier for us in the long term to slim down to using just one, and only create a separate data structure when we absolutely need it.