cc-ing iannucci@ and nodir@; estaab@ said this will probably break soon, can one of you two comment?

I think it would be better if dashboard scripts did not assume the format of the log URLs. However, currently there is no non-deprecated API in recipe land or on the web (RPCs) to get log URLs. Milo API exposes log URLs given master, builder and build number, but it is deprecated, so I don't have a future-proof solution.

For now, please consider checking if LOGDOG_COORDINATOR_HOST, LOGDOG_STREAM_PROJECT and LOGDOG_STREAM_PREFIX env variables are present. If they are, construct a logdog URL like this:

https://${LOGDOG_COORDINATOR_HOST}/v/?s=${QUERY_ESCAPE_OF(${LOGDOG_STREM_PROJECT}/${LOGDOG_STREAM_PREFIX}/recipes/steps/${STEP_NAME}/**}

Robbie, this is related to our discussion that steps are UI and should be used by client code, but here we have logs that may contain something that programs may need to interpret. I don't know if they should, but in any case, we should consider logs before declaring that steps must not be a part of build output.

Erik - this is notable and interesting based on recent discussions.

+1 to Nodir's solution for constructing log links to unblock current work.

To Nodir and Robbie on steps as UI: I understand where this is coming from but I think we can let steps be data with some modifications. Steps don't have types or schema and depending on their contents (or step name...) is fragile. To address this we could possibly allow steps to optionally have a UUID that tools can check against, possibly with a schema to ensure certain metadata exists as well.