Every deploy tags an image with its version — that's what makes a rollback a docker run rather than a rebuild. It has also quietly put 7.7 GB on the host, 4.3 GB of it reclaimable, six ihasmail images at ~650 MB each. docker image prune won't help: they're tagged, which is the entire point of them.
The script that creates them now removes them, keeping the newest IHASMAIL_KEEP_VERSIONS (three by default; 0 keeps everything).
Two things it's careful about, both reasoned about rather than learned the hard way:
It runs only after the new container reports healthy, so a rollback target is never dropped while the thing meant to replace it is still unproven.
It excludes the image the container is running, by asking docker what that is rather than assuming it sorts newest. After a rollback it doesn't — the running image is an old one, and naive keep-the-newest-N would delete the image in use. Docker would refuse, but being refused isn't the same as not having tried.
Tested with a stub on PATH, so the real pipeline and xargs run
case
result
KEEP=3, running newest
removes 2.0 only
KEEP=1, running newest
removes 2.16.63, 2.16.61, 2.0
KEEP=0
silent, removes nothing
:current
never listed for removal
rollback — running 2.16.61, the 4th newest, KEEP=1
removes 2.16.64, 2.16.63, 2.0 — the running image is spared
The live verification
Records delete all spam as confirmed on the live 0.16.19 today: Junk Mail emptied, and Deleted Items stayed empty afterwards.
That second half is the one a mock can't prove and the one the feature exists for — a folder that empties into another folder has solved nothing. It's now in Known issues / pending QA with the date, in the same form as everything else there.
Docs and the deploy script only — no application code.
## The images
Every deploy tags an image with its version — that's what makes a rollback a `docker run` rather than a rebuild. It has also quietly put **7.7 GB** on the host, **4.3 GB of it reclaimable**, six ihasmail images at ~650 MB each. `docker image prune` won't help: they're tagged, which is the entire point of them.
The script that creates them now removes them, keeping the newest `IHASMAIL_KEEP_VERSIONS` (three by default; `0` keeps everything).
**Two things it's careful about**, both reasoned about rather than learned the hard way:
- It runs **only after the new container reports healthy**, so a rollback target is never dropped while the thing meant to replace it is still unproven.
- It **excludes the image the container is running**, by asking docker what that is rather than assuming it sorts newest. After a rollback it doesn't — the running image is an old one, and naive keep-the-newest-N would delete the image in use. Docker would refuse, but being refused isn't the same as not having tried.
### Tested with a stub on PATH, so the real pipeline and `xargs` run
| case | result |
|---|---|
| `KEEP=3`, running newest | removes `2.0` only |
| `KEEP=1`, running newest | removes `2.16.63`, `2.16.61`, `2.0` |
| `KEEP=0` | silent, removes nothing |
| `:current` | never listed for removal |
| **rollback** — running `2.16.61`, the 4th newest, `KEEP=1` | removes `2.16.64`, `2.16.63`, `2.0` — **the running image is spared** |
## The live verification
Records **delete all spam** as confirmed on the live 0.16.19 today: Junk Mail emptied, and **Deleted Items stayed empty afterwards**.
That second half is the one a mock can't prove and the one the feature exists for — a folder that empties into another folder has solved nothing. It's now in *Known issues / pending QA* with the date, in the same form as everything else there.
Docs and the deploy script only — no application code.
**Merged** 2026-08-26 as coffey-labs/ihasmail@e2f17f6f4945
<sub>Rebuilt from: git history, session transcript.</sub>
This repo is archived. You cannot comment on issues.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The images
Every deploy tags an image with its version — that's what makes a rollback a
docker runrather than a rebuild. It has also quietly put 7.7 GB on the host, 4.3 GB of it reclaimable, six ihasmail images at ~650 MB each.docker image prunewon't help: they're tagged, which is the entire point of them.The script that creates them now removes them, keeping the newest
IHASMAIL_KEEP_VERSIONS(three by default;0keeps everything).Two things it's careful about, both reasoned about rather than learned the hard way:
Tested with a stub on PATH, so the real pipeline and
xargsrunKEEP=3, running newest2.0onlyKEEP=1, running newest2.16.63,2.16.61,2.0KEEP=0:current2.16.61, the 4th newest,KEEP=12.16.64,2.16.63,2.0— the running image is sparedThe live verification
Records delete all spam as confirmed on the live 0.16.19 today: Junk Mail emptied, and Deleted Items stayed empty afterwards.
That second half is the one a mock can't prove and the one the feature exists for — a folder that empties into another folder has solved nothing. It's now in Known issues / pending QA with the date, in the same form as everything else there.
Docs and the deploy script only — no application code.
Merged 2026-08-26 as coffey-labs/ihasmail@e2f17f6f49
Rebuilt from: git history, session transcript.