Skip to content

FreeWilly 1.0.10

Choose a tag to compare

@alegauss alegauss released this 31 Aug 13:09
· 59 commits to main since this release

Watching a run, without leaving the read surface

freewilly read logs <name> --follow closes the last hole in the read surface. Every diagnostic on
this machine was already a freewilly read except one: a database seed or a migration that prints
for two minutes still sent a session to docker compose logs -f, and a session that has dropped to
the docker CLI once tends to stay there for the next check too.

--until returns the moment the line arrives. read logs shop-db-1 --follow --until "database system is ready" is what read verify --wait already was for a port, applied to whatever the
container prints. It exits 0 when the line lands and 1 when it does not, so it works as a gate.

It is never open-ended. Three things bound it: the pattern, --timeout 90s, and the token
budget, so a container printing faster than the ceiling allows ends the follow rather than the
session's context. Following starts from now, because the run you want to watch is the one you are
about to make; --since <cursor> replays what came before.

Nothing prints until it returns. The reader is an agent, which sees stdout once the process has
ended, so a live scroll buys it nothing and --level, --dedup, the budget and the cursor all still
apply to the whole payload. Ctrl+C is a normal ending and keeps what was read.

A follow says which ending stopped it

A pattern that never arrives exits 1, and your next move differs by reason, so the last line names
which reason it was:

until   "seed complete" did not arrive in 90s
until   "seed complete" did not arrive, and the log ended
until   "seed complete" did not arrive, and the budget filled first: raise --budget, or --out to a file
until   "seed complete" had not arrived when this was stopped
until   "seed complete" did not arrive, and the container is gone

Only the first names a duration, because it is the only one that waited one.

A follow survives compose up. A log stream belongs to one container id and a recreate makes a
new one, so the stream ends while the service is running, printing, and about to print the line you
asked for. Where you addressed a role, meaning svc:<project>/<service> or a name, which compose
reuses, the follow crosses to the replacement and marks the seam in the payload:

O  migrating
--- svc:shop/api was replaced: aaaaaaaaaaaa -> bbbbbbbbbbbb ---
O  listening on :8080

It crosses once, because a service in a crash loop is recreated over and over. An id prefix names
one container and no other container is it, so there the follow ends.

Proving a path is gone

read verify --request answered one question: does this path answer. A 404 was therefore always a
failure, so the proof that a retired page had gone was the run that printed red, and the session had
to hold in its head that this particular red was the green one.

--expect turns the row into "this path answered what I named". read verify shop-web-1 --request /retired --expect 404 exits 0 and prints [ok], and --expect 404,410 takes either. A
missed expectation prints the status that arrived instead. --request with no --expect still means
2xx or 3xx, so nothing already written changes, and --wait now waits for a removal to take effect
as readily as for an arrival.

Fixes

A refusal names the value that would have worked. --request healthz used to answer "healthz is
not a path: it begins with a slash", stating the false half as a fact about what you typed.

Two help rows fit the terminal. read context and do reclaim ran past the width, and a folded
summary puts its tail in column 0, where a verb name goes.

A long follow costs what it reads. Matching a pattern across frame boundaries re-split the whole
buffer on every chunk, which is quadratic once --out lifts the token ceiling on purpose.

Install

Download FreeWilly-Setup-1.0.10.exe and check it against SHA256SUMS.txt. Upgrading keeps the
distribution and everything in it.