I was investigating a failure recently where the tests run against every day against a Nightly build. I had (and was able to use) the dates of the builds to determine the initial regression range, but it would be preferable to have the build identifiers or revisions of the builds in use. I intend to add some logging to the test suite so that I have this, but it occurred to me to check the geckodriver log. I didn't see anything in there, but I wonder if it might be possible? The browser version is shown in the capabilities returned from starting a session. Could we include the build id, changeset, and branch (central, beta, etc)?

When running Marionette tests we print the following details via mozversion: mozversion application_buildid: 20180905094656 mozversion application_changeset: d8c933c4bd25ab7bf6f53a8d9235577c6e517d01 mozversion application_display_name: Nightly mozversion application_id: {ec8030f7-c20a-464f-9b0e-13a3a9e97384} mozversion application_name: Firefox mozversion application_remotingname: firefox mozversion application_vendor: Mozilla mozversion application_version: 64.0a1 mozversion platform_buildid: 20180905094656 mozversion platform_changeset: d8c933c4bd25ab7bf6f53a8d9235577c6e517d01 mozversion platform_version: 64.0a1 I don't think we need them all but some would be indeed great to see in the log.

I generally find it pretty annoying that this is printed to stdout when using Marionette, but I guess with geckodriver we have the option to print this using a finer debug verbosity, which would be fine with me. This would involve porting the Python mozversion code to the Rust mozversion library in testing/mozbase/rust/mozversion.

Sure. And to note the important bit we should print via info is the buildid or changeset id, so that we can match a Firefox build to a specific changeset. It will help a lot investigating JS errors by following the line numbers in the stack.