Status Update
No update yet.
Comments
mi...@gmail.com
OMG, I figured out the problem, it's fine like this:
$ gcloud beta app versions list --service=demo --sort-by=~last_deployed_time --limit=1
SERVICE VERSION.ID TRAFFIC_SPLIT LAST_DEPLOYED SERVING_STATUS
demo 20200516t195011 0.00 2020-05-16T21:50:15+02:00 SERVING
So when a --limit (or --format) is used, the --sort-by must use the name of the data "field" not the label of the "column".
I don't suppose we could make it so that this combination is detected and the user gets a helpful error message, like "cannot sort by LAST_DEPLOYED (use actual field name instead)" instead of it just silently ignoring it and presenting the confusion result? Just a thought.
ni...@google.com
Hello,
Thanks for letting me know about this.
I understand your concerns, per
I have consulted the Cloud SDK Enginnering Team regarding this behavior. So they will investigate further on your issue.
Best Regards
Nibrass
wu...@google.com
js...@google.com
kn...@google.com
- One is that instead of throwing an error when a non-existent field name is passed to the --sort-by flag, the results are listed in the default order instead, which can often create an impression the command worked as intended while displaying results in an incorrect order.
Able to reproduce - any random identifier passed to the --sort-by flag is silently ignored if it's not a valid one (ex. --sort-by some_random_thing) and the results are displayed in the default order.
This is true for compute instances list and container clusters list as well, so I assume it an issue in core gcloud code rather than any one surface.
- Second is that when using the --limit or --format flag in addition to the --sort-by flag, the sorting also doesn't work with the label last_deployed (label for field last_deployed_time).
In this case, adding or removing limit/format flags made no difference - the sorting was always wrong if the label was passed instead of the field. In other words, it always only worked if the field name (last_deployed_time) was passed, which is obscured because a plain app versions list command shows the column name as last_deployed'.
vo...@google.com
Yes, the 1st point re. better error handling for unknown fields to --sort-by (and ideally all other similar flags/arguments), instead of silently ignoring, would certainly help to reduce confusion in such cases.
Re. the 2nd point, we can perhaps formulate this a bit differently: That probably has nothing to do with --limit or --format per se, but the suggestion there is that, in an ideal world, if the gcloud CLI shows you a label (such as LAST_DEPLOYED) it would be "nice" if one could just directly use that in a flag like --sort-by (and ideally all other similar flags/arguments), as an alternative to having to know the internal field name (such as last_deployed_time).
Perhaps best to split this up into 2 completely separate and unrelated issues, and make them both block this? For prioritization, the former (Error instead of ignoring unknown field names in flags like --sort-by) seems more important to me than the latter (Also accept end-user visible UI labels instead of only internal field names in flags like --sort-by).
Description
Check this out, it seems to me that --limit is applied BEFORE --sort-by, which seems wrong:
Do you see what I mean?