JUST-PROFILE(5)

💖 JUST-PROFILE(5) 💖

okay so bestie, buckle up, because today we're decoding just-profile(5) — the manual page that lives in the File Formats Manual section and explains the format of profile files written by just-mr(1) and justbuild(1). it's literally the receipts of your build. no cap. 🎀

---

✨ NAME ✨

just-profile — the format of profile files written by just-mr(1) and justbuild(1). it's giving "here's what actually happened when you ran the thing" 💅

---

🌸 DESCRIPTION 🌸

so here's the tea ☕: if profiling is turned on through the "invocation log" key in the just-mrrc(5) file, then just-mr(1) can be told to write a metadata file, and the launched justbuild(1) process gets told to write a profile file. and guess what — both files contain a single JSON object. one object each. that's it. that's the whole format. iconic behavior honestly.

📓 Metadata file

the metadata file is carrying the following info, key by key:

• for the key "cmdline" you get the argument vector for the process it will execv(3) to. and as with all launches by just-mr(1), the program is the zeroth entry of the argument vector. (yes, argv[0] is right there being the program name, as it should be 👑)
• for the key "configuration" you get the blob identifier of the just-repository-config(5) that gets passed to the launched process — but only if such a config is passed. no config, no key, periodt.
• for the key "time" it's the time of the invocation in seconds since the epoch. classic.
• for the key "context" you get a map of the environment variables that were requested to be included in the metadata file, with the variable name as key and the value of the variable as value (peep the "context variables" field of the "invocation log" key in the just-mrrc(5) file if you wanna go deeper 🫶).

🔥 Profile file

and the profile file? she's got the following info:

• for the key "subcommand" — the subcommand that was executed. obviously.
• for the key "subcommand args" — the positional arguments that were provided for that subcommand.
• for the key "target" — the target that was analysed/built/installed, as full qualified name.
• for the key "configuration" — the build configuration in which the target was analysed/built/installed.
• for the key "remote" — an object describing the remote-execution configuration. the following keys get used:
  • if a remote-execution endpoint is used, for the key "address", a string of the form address:port is given. yes, with the colon. yes, both parts. 💅
  • for the key "properties" the remote-execution properties are specified (naturally as an object, like, of course it's an object).
  • for the key "dispatch" the dispatch list is given as an array of pairs (arrays of length two) of a property map and an endpoint as address:port string.
• for the key "exit code" — the exit code of the justbuild(1) process.
• for the key "analysis errors", if present, a list of error messages, each one describing an error that occurred during analysis. 😭
• for the key "actions" — an object. for each action that was looked at in the build phase there's an entry, with the key being the action identifier; that identifier is the same one as in the just-graph-file(5) that gets written as a result of the --dump-graph option. the value is an object with the following entries:
  • for the key "cached" a boolean indicating if the action was taken from cache. (slay or nah 💀)
  • for the key "time" — for non-cached actions — the build time in seconds.
  • for the key "exit code" the exit code of the action, if not 0.
  • for the key "artifacts" an object with keys the output paths and values the hashes of the corresponding artifacts as hex-encoded strings.
  • for they keys "stdout" and "stderr" the hashes of stdout and stderr, respectively, as hex-encoded strings — provided the respective output is non-empty. (yes the original says "for they keys", we are not fixing it, we respect the source material 🙈)
• for the key "start time" — the start time of the invocation in seconds since the epoch.
• for the key "build start time" — the start time of the build phase (if any) in seconds since the epoch.
• for the key "build stop time" — the stop time of the build phase (if any) in seconds since the epoch.
• for the key "stop time" — the stop time of the invocation in seconds since the epoch.

lowkey this whole file is just timestamps and hashes and vibes, and highkey that's all you ever need to debug a build bestie 🦋

---

🌈 See also 🌈

just-mr-rc(5), just-graph-file(5), just-mr(1), justbuild(1) — go read them, they're the supporting cast and they ate 💖

---

and that's a wrap!! this page came to you straight from the File Formats Manual, filed under JUST-PROFILE(5), and honestly? she understood the assignment. stay profiled, stay caffeinated, and don't forget the zeroth entry bestie ✨🧚💜