builds listed out of order in build-task list-builds table output

[mmacy]

When viewing the list of builds with az acr build-task list-builds [...] -o table, builds that are running aren't listed at the top of the list. This makes it more difficult to notice which build is latest, and which (if any) are currently running.

Example output below. Notice that the currently running build, aa8, is listed after the previous build, aa7.

BUILD ID    TASK             PLATFORM    STATUS     TRIGGER       STARTED               DURATION
----------  ---------------  ----------  ---------  ------------  --------------------  ----------
aa7                                      Succeeded  Manual        2018-04-30T17:59:12Z  00:00:35
aa8         buildhelloworld  Linux       Running    Image Update  2018-04-30T17:59:38Z
aa6         buildhelloworld  Linux       Succeeded  Manual        2018-04-30T17:49:41Z  00:00:55
aa5                                      Succeeded  Manual        2018-04-30T17:46:41Z  00:00:55
aa4         buildhelloworld  Linux       Succeeded  Git Commit    2018-04-30T17:45:05Z  00:00:35
aa3         buildhelloworld  Linux       Succeeded  Manual        2018-04-30T17:42:38Z  00:00:45
aa2         buildhelloworld  Linux       Succeeded  Manual        2018-04-30T17:39:36Z  00:00:40
aa1                                      Succeeded  Manual        2018-04-30T17:26:28Z  00:00:45

[ehotinger]

Proposal: order by status then by build id desc

[djyou]

Builds returned by the service are ordered by the timestamp (aka, build id) when they are triggered. To me a stable ordering makes more sense as a few implementations (e.g., show logs of the last updated build) would be tricky and confusing otherwise.

Client, if interested in a certain value of a certain column, can apply either a server side filter by specifying, for example, --name MyBuildTask and/or --build-status Succeeded, or a client side querying by specifying --query.

[ehotinger]

@djyou there's definitely a bug in the above because it doesn't do what you're saying. It's not being sorted by timestamp, aa7 and aa8 are out of order. Unless that's from an old CLI. Anyways, I still think it makes sense for all of the list builds commands to filter by status and then by time. It's a much more natural way to see things that are in progress than just time, since there's going to be a huge variance in build completion times. Imagine the mess it'd look like if you had Windows builds and Linux builds at the same time. Huge difference in start/stop times.

The current show logs behavior is only useful for tiny pipelines with no builds in parallel. It shouldn't be a major feature that anyone depends on, so just showing the latest timestamp will get it correct 99.99% of the time.

[djyou]

@ehotinger They are ordered by record's last updated timestamp. The above example means aa7 has an update later than that of aa8.

The problem with ordering by status is that, given we have 8 statuses, if I have many Succeeded and Failed but a few builds in other statues. How will you order them meaningfully? Always show the many Succeeded (or Failed) builds before showing everything else, even if they are old and may overwhelm more recent builds? I don't see a simple solution here without introducing complex ordering (e.g., order by day, then status, then timestamp, etc.).

The fact that we support both server and client side filtering already provides enough flexibility and any additional (implicit) ordering done by us would be confusing IMO.

[mmacy]

Because the last updated timestamp isn't shown in the output, it's not readily apparent in the table view why it's ordered this way.

What about ordering by build start time (descending)?

[djyou]

lastUpdatedTime is available in json, but as agreed, it's not shown in table. We can add it if needed, but I do agree with you ordering by build start time might make more sense here. We can tweak the message of show logs to be the last started build. /cc @SteveLas

[mmacy]

A potential drawback to start-time-descending format would be that a long-running build could get pushed further down the list, and eventually get hidden by the later N builds (and stay there, even after it completes). With the last-updated ordering, it'd pop to the top when it completes.

[mmacy]

Sorry for the spam--one other option: order by duration, then last updated. This would pop currently running builds to the top (since duration is null), but preserve the current last updated sort for all other builds, regardless of status.

[SteveLasker]

I think we all agree we'll need the ability to filter and change ordering. The question seems to be, what should the default be.
@ehotinger brings up a good point, when we start mixing long running builds (assumed to be .NET FX and WindowsServerCore, but could be Java or who knows what), with quick running builds, perhaps spall test containers.
After running lots of builds over the weekend (I'm up to aa64), the initial build/queue time seems the most normal. But, I'm also looking at a watch -n1 az acr build-task list-builds output. Meaning, the top is at the top of my screen. If I listed builds, and 50 scrolled by, it would be harder.
When do we get the default of 15 data rows?
Suggest we leave as build/queue time for now, and see what happens as we get more diverse builds and feedback.

[djyou]

@SteveLas It's been merged and will be released soon by CLI team. You can run the docker image https://github.com/Azure/azure-cli#docker or install Edge release https://github.com/Azure/azure-cli#edge-builds for now.

[SteveLasker]

@djyou, can we tweak this a bit to show ordering based on initial queue date? When using watch, the ordering bounces and it's a bit confusing to track.

[djyou]

This has been fixed from the server side, now list builds are ordered by their createTime.