CODEWITHSUNDEEP
bazel
JMAA
JMAA

Reputation: 2067

Bazel logs for postmortem analysis: what were you doing when you crashed?

Suppose you're using bazel to manage builds for a large and diverse project (what it's designed to do). Then you start getting reports of mid-build crashes. Maybe these are on developer machines you don't have access to, maybe they're in transient CI containers, the point is you don't have reliable access to the machine at the time of most crashes.

Suppose most of these crashes are the bazel server dying. Perhaps it hung on a grpc call, perhaps it was a Java heap OOM exception.

How can you:

  1. enable good logging by default (of both bazel client and server) with which postmortems can effectively be performed?

  2. provide timestamped logs of when bazel started to perform a build or test action, and when it finished each action (and thereby be able to find out what actions were being run at the time of crash and may be at fault)?

Any help on enabling good by-default logging for bazel builds is appreciated. I'm not interested in things like --subcommands or --verbose_failures which spam to stdout/stderr (since most of the time that's just noise hiding the more commonly useful information there). I'm also aware of --explain, but it typically outputs very little and almost nothing of value.

I guess a rephrasing of my question might be: how can I achieve what --explain probably should be doing?

Upvotes: 1

Views: 524

Answers (1)

László
László

Reputation: 4281

--show_timestamps adds timestamps to the build output.

--announce_rc displays the effective flags from RC files.

The Bazel server process also writes logs, a new one for each server run. These are verbose, but might help with crash forensics. $(bazel info output_base)/java.log is a symlink that points to the latest log; bazel info server_log reports the target of that symlink. You need a way to retrieve these from CI, which I understand could be infeasible, but maybe isn't.

Upvotes: 0

Related Questions