Overhaul `brioche jobs` command

[kylewlacy]

We have some basic tooling for viewing and debugging failed builds, via the brioche jobs subcommand:

• brioche jobs logs $event_file: View stdout / stderr / metadata from a process recipe that failed to bake¹
• brioche jobs debug-shell $event_file: Spawn an interactive shell within the sandbox of a process recipe that failed to bake¹

...where $event_file is the path to an events.bin.zst file that was written during the build (see "New format for process failures" from the Brioche v0.1.4 announcement for more context).

It's always a bit annoying to copy/paste or write out the path to this file though! The file path currently includes a ulid, so it can often take a lot of typing to disambiguate it from other paths even with tab-completion, and just having to skim the long error output to spot the path is not very fun. It'd be nicer if both of these could be more ergonomic. At the same time, there's more information we could surface too about past builds / build failures.

So, a few things I want to do:

1. Record builds and jobs in database

When you run brioche build, that can trigger either 0 jobs if everything's cached locally, or dozens / hundreds of jobs if everything needs to be built from source. We should keep track of each build and job in the database, which can then be used with our new "jobs" commands. I think the tables could look something like this:

• jobs: tracks process recipes we ran (possibly download recipes too)
  • build_projects_id: foreign key for build_projects.id, project + build that triggered this job
  • started_at
  • stopped_at
  • result ("succeeded" | "failed" | null)
  • recipe_hash
  • recipe_meta: recipe metadata if known
  • pid: process PID if known
  • local_path: the local path containing the events.bin.zst file, sandbox root, etc.
• builds: created when we run a top-level CLI command
  • id
• build_projects: lists the projects of a build
  • id
  • build_id: foreign key for builds.id
  • project_hash
  • local_project_path: path if it's a local project
  • registry_project_name: name if it's a project from a registry

Together, these should be enough to basically show what happened during a build. We can query all the jobs in a build and piece together which parts succeeded and which parts failed, see how long a previous build took, see where we spent time during a build, see why we built what we did, diff two builds to see what changed, etc.

2. Add new brioche job commands to replace old commands

I'm proposing brioche job to replace brioche jobs (singular I think is more common for a group of actions, e.g. docker image). The new commands will look like this:

• brioche job list: List jobs (most recent first), with project, status, and duration
  • Defaults to listing all jobs, could follow-up by filtering e.g. by project, status, etc.
• brioche job show $job: Show a single job with lots of detail
• brioche job logs $job: Show logs from a job
• brioche job debug-shell $job: Start a debug shell for a job

The $job argument can be a few different things, and is optional:

• When omitted, defaults to the most recent failed job
• failed: The most recent failed job
• last: The most recent job, regardless of status
• -1, -2, -3, etc.: The last failed job, the 2nd-last failed job, etc.
• Can be specified as a job ID. It would be kinda neat to do this like git, where we allow specifying the unique part of a long string
• Can be specified as a recipe ID too (selects most recent job for the recipe)
• Can be specified as a PID (handy because this is what we show in the TUI)

The reason most things are scoped to failed jobs is because, (1) that's the most useful thing to look at, and (2) by default, those are the only jobs where we keep detailed output by default. It could also make sense to keep the last (n) successful jobs too, as a future change.

Footnotes

1. You can also inspect a non-failed process too that was kept using the --keep-temps flag ↩ ↩²