kat
beeba66efe
both on a test level and for the whole thing. i think the reporter or
registrar abstractions should deal with all timeouts, and just feed
elapsed time through all the functions: update() gets time for the
specific test, and finalize passes you the total time. this way you
don't need to do the same logic in every reporter, and you also give
a suggestion to reporter writers (i.e.: you in the future) to expose
test durations. actually tbh per-test isn't possible anywhere but in the
executor, especially when taking potential future parallel execution
into account
on the topic of parallelism: per-test is wall clock for that test,
regardless of perceived time, because no other number is useful. whole
thing is wall clock too, not cpu time
remember:
- use monotonic clocks!! we need elapsed time, not absolute time
- format them to more readable strings like “15h 12m” instead of
“54738 seconds”. once things get large we can be less precise
for the go reporter: ask ozy if the go one already measures it. if so
then don't even bother serializing it
for the stream reporter: the live feed should include per-test time in
brackets or something. the final tree should only include timeout for
outliers on the long side (just shove a box plot-esque algo on it), and
if a flag is given print it for all nodes, and if another flag is given
print the n longest tests. the total time should be in the summary line
at the end in brackets à la pytest
for the dom reporter, we do the same as with the stream reporter's
outlier detection, and have a checkbox or button to dynamically
show/hide all timeouts, and another button to toggle a widget of sorts
that shows up right above the result tree which includes the n longest
tests. all these buttons should be on the same line as the summary
(successes/failures/skips). the total time should be included in the
“execution finished” text form the previous commit, i.e. “execution
finished in 15s”
Hakurei is a tool for running sandboxed desktop applications as dedicated subordinate users on the Linux kernel. It implements the application container of planterette (WIP), a self-contained Android-like package manager with modern security features.
Interaction with hakurei happens entirely through structures described by package hst. No native API is available due to internal details of uid isolation.
Notable Packages
Package container is general purpose container tooling. It is used by the hakurei shim process running as the target subordinate user to set up the application container. It has a single dependency, libseccomp, to create BPF programs for the system call filter.
Package internal/pkg provides infrastructure for hermetic builds. This replaces the legacy nix-based testing framework and serves as the build system of Rosa OS, currently developed under package internal/rosa.
Dependencies
container depends on:
- libseccomp to generate BPF programs.
cmd/hakurei depends on:
- acl to export sockets to subordinate users.
- wayland to set up security-context-v1.
- xcb to grant and revoke subordinate users access to the X server.
cmd/sharefs depends on:
- fuse to implement the filesystem.
New dependencies will generally not be added. Patches adding new dependencies are very likely to be rejected.
NixOS Module (deprecated)
The NixOS module is in maintenance mode and will be removed once planterette is feature-complete. Full module documentation can be found here.