<feed xmlns='http://www.w3.org/2005/Atom'>
<title>skiff.git/internal/lock, branch master</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<id>https://git.mikeanthonywild.com/skiff.git/atom?h=master</id>
<link rel='self' href='https://git.mikeanthonywild.com/skiff.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.mikeanthonywild.com/skiff.git/'/>
<updated>2026-08-08T00:02:40Z</updated>
<entry>
<title>Add per-app flock locking around deploy, config change, rollback, new-app</title>
<updated>2026-08-08T00:02:40Z</updated>
<author>
<name>Claude</name>
<email>noreply@anthropic.com</email>
</author>
<published>2026-08-08T00:02:40Z</published>
<link rel='alternate' type='text/html' href='https://git.mikeanthonywild.com/skiff.git/commit/?id=acde3827f60bc90738429fa490a36a1856a93283'/>
<id>urn:sha1:acde3827f60bc90738429fa490a36a1856a93283</id>
<content type='text'>
Nothing previously serialized these against each other, so concurrent
invocations for the same app (a manual config change racing an
in-flight deploy, a double git push, a rollback mid-deploy) could
interleave snapshot/apply/restart/rollback sequences against the same
dataset and jail. The lock file lives under a new LocksDir, outside
any per-app ZFS dataset, since those datasets get rolled back on a
failed health check or a manual rollback.
</content>
</entry>
</feed>
