fix(ci): three background-removal e2e tests fail because CI never sets REMBG_URL #287

New Issue

2026-09-03T16:33:25-05:00

bermudalamb commented

2026-09-03 16:33:25 -05:00

main is red. Run 786 on 86095cb reports Playwright: 157 passed, 3 failed, 0 flaky, 0 skipped, and every other step in that job passed — backend 413 unit, 389 integration, both builds, the scan itself.

The cause

The three failures are the background-removal cases from #281:

intake-submit.spec.ts → "offers to remove the background, already ticked"
intake-submit.spec.ts → "lets a sender turn it off and still send"
admin-draft-queue.spec.ts → "offers to remove the background on each photo"

All three assert a control that only renders when the server reports the feature as configured. REMBG_URL appears nowhere in .gitea/workflows/, so isRembgConfigured() is false, GET /api/intake/:token and GET /api/admin/item-drafts both return backgroundRemoval: false, and neither the submitter's checkbox nor the admin's button is rendered. The tests are correct and the application is correct; the environment the tests run in is missing one variable.

How it got in

#281 added $env:REMBG_URL to scripts/start-local.ps1 and stopped there. The equivalent line in the job that actually runs the e2e suite was never added, and the three tests were merged unrun — they were verified locally, against a stack that did have the variable, and handed over as outstanding rather than being run before the merge. So nothing caught it until it hit main.

The fix

Set REMBG_URL in the sonarqube.yml job env, beside DEMO_MODE and UPLOADS_DIR, which is where the backend the e2e run drives gets the rest of its configuration.

It does not need to resolve. Nothing in the e2e suite reaches the sidecar: the worker only removes a background after a draft is written, and drafting needs an ANTHROPIC_API_KEY that CI does not have. Standing up a real rembg in CI would mean a 4.24 GB image and about forty seconds of startup for tests that only assert a control is on screen.

Worth considering while here

The deeper problem is not the missing line, it is that a variable which changes rendered behaviour lives in two places that nothing compares. composeEnvironment.test.ts exists for exactly this class of failure — it caught #107 and #118, where envValidation and a compose file disagreed — but it only guards the deploying compose files, not the CI workflow. Whether that guard should extend to .gitea/workflows/ is worth a decision rather than another hand-added line.

Refs #281

`main` is red. Run 786 on `86095cb` reports `Playwright: 157 passed, 3 failed, 0 flaky, 0 skipped`, and every other step in that job passed — backend 413 unit, 389 integration, both builds, the scan itself. ## The cause The three failures are the background-removal cases from #281: - `intake-submit.spec.ts` → "offers to remove the background, already ticked" - `intake-submit.spec.ts` → "lets a sender turn it off and still send" - `admin-draft-queue.spec.ts` → "offers to remove the background on each photo" All three assert a control that only renders when the server reports the feature as configured. `REMBG_URL` appears nowhere in `.gitea/workflows/`, so `isRembgConfigured()` is false, `GET /api/intake/:token` and `GET /api/admin/item-drafts` both return `backgroundRemoval: false`, and neither the submitter's checkbox nor the admin's button is rendered. The tests are correct and the application is correct; the environment the tests run in is missing one variable. ## How it got in #281 added `$env:REMBG_URL` to `scripts/start-local.ps1` and stopped there. The equivalent line in the job that actually runs the e2e suite was never added, and the three tests were merged unrun — they were verified locally, against a stack that did have the variable, and handed over as outstanding rather than being run before the merge. So nothing caught it until it hit `main`. ## The fix Set `REMBG_URL` in the `sonarqube.yml` job env, beside `DEMO_MODE` and `UPLOADS_DIR`, which is where the backend the e2e run drives gets the rest of its configuration. It does not need to resolve. Nothing in the e2e suite reaches the sidecar: the worker only removes a background after a draft is written, and drafting needs an `ANTHROPIC_API_KEY` that CI does not have. Standing up a real `rembg` in CI would mean a 4.24 GB image and about forty seconds of startup for tests that only assert a control is on screen. ## Worth considering while here The deeper problem is not the missing line, it is that a variable which changes rendered behaviour lives in two places that nothing compares. `composeEnvironment.test.ts` exists for exactly this class of failure — it caught #107 and #118, where `envValidation` and a compose file disagreed — but it only guards the deploying compose files, not the CI workflow. Whether that guard should extend to `.gitea/workflows/` is worth a decision rather than another hand-added line. Refs #281

bermudalamb referenced this issue from a commit

2026-09-03 16:36:43 -05:00

fix(ci): give the end-to-end backend a REMBG_URL so its controls render (#287)

bermudalamb referenced this issue

2026-09-03 16:37:22 -05:00

fix(ci): give the end-to-end backend a REMBG_URL so its controls render (#287) #288

bermudalamb referenced this issue from a commit

2026-09-03 16:37:34 -05:00

Merge pull request 'fix(ci): give the end-to-end backend a REMBG_URL so its controls render (#287)' (#288) from fix/287-ci-rembg-url into main

bermudalamb referenced this issue from a commit

2026-09-03 16:58:53 -05:00

fix(scripts): make the database the e2e suite reads a recorded fact (#273)

bermudalamb referenced this issue

2026-09-03 16:59:09 -05:00

fix(scripts): make the database the e2e suite reads a recorded fact (#273) #291

bermudalamb commented

2026-09-04 09:05:32 -05:00

Fixed and confirmed. Merged as PR #288.

REMBG_URL is now set in the sonarqube.yml job env, pointing at a URL that deliberately does not resolve — nothing in the suite reaches the sidecar, because removal only happens after a draft and CI has no ANTHROPIC_API_KEY.

Confirmed rather than assumed: runs 809 and 810 on main at b8ea33f both succeeded, with Frontend end-to-end tests with coverage passing. The three background-removal cases that were failing now pass in CI.

The deeper gap this issue raised is left open deliberately and moves to the cleanup work: a variable that changes rendered behaviour still lives in two places nothing compares. composeEnvironment.test.ts guards the deploying compose files but not .gitea/workflows/. Extending it would have caught this, and it is a decision rather than an obvious yes.

Fixed and confirmed. Merged as PR #288. `REMBG_URL` is now set in the `sonarqube.yml` job env, pointing at a URL that deliberately does not resolve — nothing in the suite reaches the sidecar, because removal only happens after a draft and CI has no `ANTHROPIC_API_KEY`. Confirmed rather than assumed: runs 809 and 810 on `main` at `b8ea33f` both succeeded, with **Frontend end-to-end tests with coverage** passing. The three background-removal cases that were failing now pass in CI. The deeper gap this issue raised is left open deliberately and moves to the cleanup work: a variable that changes rendered behaviour still lives in two places nothing compares. `composeEnvironment.test.ts` guards the deploying compose files but not `.gitea/workflows/`. Extending it would have caught this, and it is a decision rather than an obvious yes.

bermudalamb closed this issue

2026-09-04 09:06:08 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bermudalamb/redefined-designs#287