Yep, we can. I'll keep this in my mind in next two weeks that I'll be re-making tryjob processing for CQ.

Great, thanks!  FTR we've just started providing result_details_json for canceled jobs in this format:

{"message": "No jobs for you!"}

in https://skia-review.googlesource.com/c/16911/

But we're happy to standardize on a format you prefer.

Ah, I didn't realize it's not yet standard. I think being able to express failure reason is very handy. I'd vote for the structure similar to other errors from buildbucket: 

"error": {
  "reason": "..."  # for machines;
  "message": "for humans"
}

+nodir@ any recommendations?

note that borenet@ is talking about Build.result_details_json field, not buildbucket response. "error" seems to imply that an error happened, but it did not necessarily happen. I'd vote for 

{
  "reason": "..."  # for machines;
  "message": "for humans"
}

in Build.result_details_json. 

Note that this applies only to Builds with status=COMPLETED, result=CANCELED

It was not standardized before because it was not possible to set result_details_json in cancelled builds until today.

yes, i understood that this is about result_details_json. The reason I proposed "error":{...} is because I thought CQ could make use of it if available in other cases, such as say run_presubmit.py recipe failing.

It seems like it might even be appropriate to have a CQ-specific field, ie:

{
  "cq": {
    "reason": "...", # for machines
    "message": "for humans"
  }
}

But again, I'm happy to use whatever makes sense across the board.

What if a build had nothing to do with CQ?

Milo could display the message too, so the standard is not specific to CQ. This build could be continuous, not necessarily a tryjob

The reason, to be interpretable by machines, must be standardized too. It is not as easy as the reason in buildbucket responses because the latter is under buildbucket control. I'd omit the reason for now, so I'm leaning proposal in #3

Fine, CQ would get "message" field if available and set it instead of generic message.

https://chrome-internal-review.googlesource.com/386828

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infra/infra_internal/+/c300716ffd7177e25020ea27dbf9b453468d2d64

commit c300716ffd7177e25020ea27dbf9b453468d2d64
Author: Andrii Shyshkalov <tandrii@chromium.org>
Date: Fri Jun 02 10:49:48 2017

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infra/puppet/+/8ebf6654555cffd6f6184664352e6e1256b0b2bc

commit 8ebf6654555cffd6f6184664352e6e1256b0b2bc
Author: Andrii Shyshkalov <tandrii@chromium.org>
Date: Wed Jun 07 13:01:44 2017

This has been deployed, but I haven't tested it end-to-end. LMK if you can verify this.

This does not seem to be working.
CL: https://skia-review.googlesource.com/c/19450
Canceled build: https://apis-explorer.appspot.com/apis-explorer/?base=https://cr-buildbucket.appspot.com/_ah/api#p/buildbucket/v1/buildbucket.get?id=8976987858612587136&_h=1&

The above message is very long; I'm going to shorten it.

So, yes doesn't work yet. The message would probably get shortened anyway, but it's surely better to shorten it in in your own scheduler.

Friendly ping. What's the status on this?

I don't have time to debug this at the moment :(

To be clear on the status: the CL linked above has a bug, but I don't see where (but certainly in test, too :)). Perhaps, I didn't properly mocked buildbucket response.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

borenet@ is this still something you'd like?