sneak/pixa
1
0 Fork 0
Code Issues 4 Pull Requests 3 Actions 13 Packages Projects Releases Wiki Activity

Acceptance test: use pixa end to end as a user before a release candidate #356

New Issue
Closed
opened 2026-11-11 20:55:28 +01:00 by clawbot · 1 comment
clawbot commented 2026-11-11 20:55:28 +01:00
Collaborator
Copy link
Copy source

Hands-on test before a release candidate, by the top-level manager's standing practice (sneak asked on 10 November whether vaultik had been tested by hand; it had not, and sfdupes then showed missing basics on first real use).

What to do

Build next fresh with the repo's own entrypoints and use pixa as a new user would, following README.md literally, every command and claim in it. Use small synthetic data in local containers; nothing RAM-heavy, and no real third-party accounts or credentials (stop and say so where one is needed).

Definition of done

  • Every defect filed as its own issue: steps, what happened, what should happen.
  • Every missing basic a user would expect filed as its own issue titled proposal: ..., assigned to sneak.
  • One comment here: a plain verdict (ready for a release candidate, or not), the issues filed, each marked defect or proposal, and anything in the README that turned out wrong. No code changes.

Model: opus-5-5

Hands-on test before a release candidate, by the top-level manager's standing practice (sneak asked on 10 November whether vaultik had been tested by hand; it had not, and sfdupes then showed missing basics on first real use). ## What to do Build `next` fresh with the repo's own entrypoints and use pixa as a new user would, following `README.md` literally, every command and claim in it. Use small synthetic data in local containers; nothing RAM-heavy, and no real third-party accounts or credentials (stop and say so where one is needed). ## Definition of done - Every defect filed as its own issue: steps, what happened, what should happen. - Every missing basic a user would expect filed as its own issue titled `proposal: ...`, assigned to sneak. - One comment here: a plain verdict (ready for a release candidate, or not), the issues filed, each marked defect or proposal, and anything in the README that turned out wrong. No code changes. Model: opus-5-5
clawbot commented 2026-11-11 21:14:17 +01:00
Author
Collaborator
Copy link
Copy source

Verdict: not ready. A new user who follows README.md literally gets a running server, but no image from it. #357 and #358 together block that first run. Deployed behind an HTTPS reverse proxy, as Deployment describes, everything tried behaved as the README says.

Filed

  • Defect: #357, README Getting Started ends at a server a newcomer cannot get an image from.
  • Defect: #358, a refused login or generator form answers a bare Forbidden - origin invalid that hides the cause.
  • Defect: #359, every start prints about 65 lines of the dependency-injection library's own log, and a startup error twice.
  • Defect: #360, make devserver fails on a fresh clone.
  • Proposal, for sneak: #361, keep the animation of animated GIF and WebP sources. Today pixa serves their first frame only, silently.
  • Proposal, for sneak: #362, fill transparent areas with white, not black, in JPEG output.

What in the README turned out wrong

Only Getting Started, as #357 details:

  • its commands skip script/bootstrap --cgo, so make build fails;
  • its config refuses the login form at http://localhost:8080/, and the section does not say so;
  • it shows no request that returns an image.

Not checked

  • script/loadtest: it runs go install on the host, which writes the shared Go module cache in the home directory.
  • The memory, /tmp and encode-time figures, and 8192x8192 sources: too RAM-heavy for this test.
  • A deploy under upaas, and Sentry: no upaas here, and no third-party account.
  • Upstream timeouts (504 and 500), 499, 503 when busy, and eviction by the disk cache limit or after 30 days.
  • After the 24-hour check, only the 304 path was exercised, by ageing the cache rows and files by hand. A changed source was not.
  • Builds on macOS, Ubuntu and Nix. Only Debian 13 and the Alpine image were tried.

Deviations

  • script/bootstrap --cgo and make build ran in a fresh debian:trixie container, not on the host, to keep libvips out of the shared nix profile.
  • The upstream was nginx serving synthetic images over plain HTTP (allow_http), on a Docker network in 198.51.100.0/24, since pixa refuses private addresses.
  • HTTPS came from Caddy with tls internal, in place of the example configs/Caddyfile's public certificate.

Model: opus-5-5

**Verdict: not ready.** A new user who follows `README.md` literally gets a running server, but no image from it. https://git.eeqj.de/sneak/pixa/issues/357 and https://git.eeqj.de/sneak/pixa/issues/358 together block that first run. Deployed behind an HTTPS reverse proxy, as Deployment describes, everything tried behaved as the README says. ## Filed - Defect: https://git.eeqj.de/sneak/pixa/issues/357, README Getting Started ends at a server a newcomer cannot get an image from. - Defect: https://git.eeqj.de/sneak/pixa/issues/358, a refused login or generator form answers a bare `Forbidden - origin invalid` that hides the cause. - Defect: https://git.eeqj.de/sneak/pixa/issues/359, every start prints about 65 lines of the dependency-injection library's own log, and a startup error twice. - Defect: https://git.eeqj.de/sneak/pixa/issues/360, `make devserver` fails on a fresh clone. - Proposal, for sneak: https://git.eeqj.de/sneak/pixa/issues/361, keep the animation of animated GIF and WebP sources. Today pixa serves their first frame only, silently. - Proposal, for sneak: https://git.eeqj.de/sneak/pixa/issues/362, fill transparent areas with white, not black, in JPEG output. ## What in the README turned out wrong Only Getting Started, as https://git.eeqj.de/sneak/pixa/issues/357 details: - its commands skip `script/bootstrap --cgo`, so `make build` fails; - its config refuses the login form at `http://localhost:8080/`, and the section does not say so; - it shows no request that returns an image. ## Not checked - `script/loadtest`: it runs `go install` on the host, which writes the shared Go module cache in the home directory. - The memory, `/tmp` and encode-time figures, and 8192x8192 sources: too RAM-heavy for this test. - A deploy under upaas, and Sentry: no upaas here, and no third-party account. - Upstream timeouts (504 and 500), 499, 503 when busy, and eviction by the disk cache limit or after 30 days. - After the 24-hour check, only the 304 path was exercised, by ageing the cache rows and files by hand. A changed source was not. - Builds on macOS, Ubuntu and Nix. Only Debian 13 and the Alpine image were tried. ## Deviations - `script/bootstrap --cgo` and `make build` ran in a fresh `debian:trixie` container, not on the host, to keep libvips out of the shared nix profile. - The upstream was nginx serving synthetic images over plain HTTP (`allow_http`), on a Docker network in `198.51.100.0/24`, since pixa refuses private addresses. - HTTPS came from Caddy with `tls internal`, in place of the example `configs/Caddyfile`'s public certificate. Model: opus-5-5
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
critical
Extremely important: data loss, a security hole, production down, or basic use impossible
 merge-ready
needs-checks
needs-decision
Waiting on a decision; no PR can proceed
 needs-rebase
needs-review
needs-rework
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
clawbot sneak (Jeffrey Paul)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/pixa#356