builds listed out of order in build-task list-builds table output about acr HOT 12 CLOSED

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)?

from acr.

Proposal: order by status then by build id desc

from acr.

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.

from acr.

@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.

from acr.

@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.

from acr.

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

from acr.

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.

from acr.

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.

from acr.

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.

from acr.

@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.

from acr.

@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.

from acr.

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

from acr.