obuilder

Merge pull request #207 from avsm/macos-secrets add macos secrets support via a /tmp entry

FreeBSD: force-remove the jail on exit to reap detached daemons Builds run in a non-persistent jail, which the kernel only auto-removes once its *last* process exits. A build step that detaches a process (e.g. a test running `git daemon --detach`, which reparents to PID 1) leaves a straggler that keeps the jail -- and its devfs mount and ZFS snapshot -- alive indefinitely. The mounts are then held busy, so the manual umounts on the success path fail with EBUSY and are ignored, and the jail leaks. On a long-lived worker these pile up until the host grinds to a halt. Replace the manual umounts with `jail -r`, run on every exit path. It SIGKILLs any straggler so the jail's release actions can unmount devfs and the cache mounts. On a clean exit the jail has already auto-removed, so this is a harmless no-op.

Fix ENOENT on shared build steps from stale log path A finished build log was parked in the Readonly state holding its in-progress path, but the store renames the build directory into place on success. A late-joining log tailer (e.g. a sibling build sharing a deduplicated step) reopening that path after the rename hit ENOENT (..., "open", ".../in-progress/<id>/log"). Retain a read-only dup of the fd in the finished state and read from it instead of reopening by path; the fd follows the file through the rename. On Windows the fd must be closed before the directory can be renamed, so it keeps reopening by path there. Add a regression test asserting a finished log stays readable after its directory is renamed.

hcs: tear down containers + reclaim orphaned snapshots so pruning can't wedge The HCS sandbox runs builds with `ctr run --rm` and relies on the run client to delete the container on exit. When a build is cancelled or times out the task is SIGKILLed and the client never completes the `--rm`, so the container is orphaned and keeps its rootfs snapshot pinned. obuilder's snapshot delete then fails, the layer leaks, and over time the leaked layers fill the store below the prune threshold, leaving the worker spinning in a perpetual (useless) prune loop. Manage the container lifecycle explicitly instead: * hcs_sandbox.run: in the finalize (every exit path) issue `ctr task delete --force` + `ctr container rm` so a cancelled or timed-out build's container is actually removed; the build error handler then frees its snapshot. * hcs_store.create: recover crash/reboot leftovers at start-up, in order: remove leftover obuilder-run-* containers (unpinning their snapshots), then for each in-progress result-tmp build remove the specific snapshot named in its layerinfo and drop the entry.

FreeBSD: force-remove the jail on exit to reap detached daemons Builds run in a non-persistent jail, which the kernel only auto-removes once its *last* process exits. A build step that detaches a process (e.g. a test running `git daemon --detach`, which reparents to PID 1) leaves a straggler that keeps the jail -- and its devfs mount and ZFS snapshot -- alive indefinitely. The mounts are then held busy, so the manual umounts on the success path fail with EBUSY and are ignored, and the jail leaks. On a long-lived worker these pile up until the host grinds to a halt. Replace the manual umounts with `jail -r`, run on every exit path. It SIGKILLs any straggler so the jail's release actions can unmount devfs and the cache mounts. On a clean exit the jail has already auto-removed, so this is a harmless no-op.