Add StartedAt field to container list output

[zk2k2]

Summary

This pull request adds support for tracking and exposing the container startedAt timestamp throughout the container lifecycle.

Fixes apple/container#302.

Changes

• Added startedAt: Date? to:
  • ContainerSnapshot
  • ClientContainer
  • PrintableContainer
• Timestamp is assigned in ContainersService.containerStartHandler using Date()
• Propagated the value through Item.asSnapshot()
• Included startedAt in:
  • container list --format json output
  • Optionally included in asRow for table display (ISO 8601 format)

[jglogan]

@zk2k2 Can you run make fmt on your end and push the changes? Right now your PRB breaks because format checks are failing.

[jglogan]

startedAt is really only relevant when the container is alive, isn't it? We might want to consider associating this value with State.alive.

[jglogan]

The thing seems a bit awkward on the SandboxService side of things (no fault of yours, you're just having to work with it) is that we have a model for runtime state that uses different types on the client (RuntimeStatus) and server (State) side.

The approach in the NetworkService is to have a NetworkState enum type that has an associated value for configuration data for the non-running states, and both config and runtime state values for the running states, and NetworkState is used on both client and server.

Let me look into whether we can take this approach here and I'll offer some guidance.

[jglogan]

@zk2k2 If you're still interested in moving this forward, have a look at the ContainersService now. The ContainersService.Item type has now been eliminated which should make adding this field a lot simpler.

[zk2k2]

Hi @jglogan, sure I'll check it out

[Mcrich23]

Hey! So sorry, but in an effort to make plugin development more possible #603 and #635 have lead to the CLI folder being renamed to ContainerCommands and that will impact the merging of your pull request. Just an FYI, so you understand the issue when you are resolving conflicts.