test(web): end-to-end enrollment install-token integration test (VS-60) #81

Merged

David merged 1 commit from test/VS-60-enrollment-e2e into main

2026-06-26 21:01:25 +02:00

David commented

2026-06-26 20:57:39 +02:00

Owner

What

Adds an end-to-end HTTP integration test for the agent-binary install-token enrollment flow (VS-60, with the download gate from VS-57), proving the device-enrollment path that VS-60 restored works end to end on the server side.

The original bug (the could not mint an agent install token: 404 Not Found error in the "Enroll a new device" dialog) was the frontend calling a server endpoint that did not exist. VS-60 added it; this test pins the contract so it cannot silently regress.

What it verifies

Stands up the real router (build_router) with a seeded user + session and drives the exact contract vervain-apps get_group_install -> mint_install_token depends on:

GET /agentbinaries/install-token with the operator session -> 200 {"token": "<non-empty>"} (the call that 404'd before VS-60).
That token, with NO session, on GET /api/v1/agent/binary/6?token=<token> -> passes the auth gate. With no fetcher configured the authorized request is 404 (empty refresher slot), distinct from the 401 an unauthorized request gets, so 404-not-401 is the "the install token authorized the unattended fetch" signal.
Negative paths: mint without session -> 401; download with no credentials -> 401; download with an unknown token -> 401; download with the operator session and no token -> authorized (browser "Download agent" button path).

Verification beyond this test

Confirmed the frontend half matches this contract on vervain-apps main: mint_install_token GETs /agentbinaries/install-token, parses body.get("token"), and builds the download URL /api/v1/agent/binary/6?token=. The only piece not exercised here is the actual Forgejo byte stream (unchanged VS-56 machinery, needs a live service-account PAT).

CI note

Lives alongside the existing tests/*.rs integration suite. CI runs cargo test --lib only by design (linking the integration-test binaries exhausts runner disk - see check.yml), so this is compile-checked by CI's cargo check --all-targets and executed by cargo test / just test locally. All 5 cases pass locally; full just pre-commit gate green (449 lib tests).

## What Adds an end-to-end HTTP integration test for the agent-binary install-token enrollment flow (VS-60, with the download gate from VS-57), proving the device-enrollment path that VS-60 restored works end to end on the server side. The original bug (the `could not mint an agent install token: 404 Not Found` error in the "Enroll a new device" dialog) was the frontend calling a server endpoint that did not exist. VS-60 added it; this test pins the contract so it cannot silently regress. ## What it verifies Stands up the real router (`build_router`) with a seeded user + session and drives the exact contract `vervain-apps` `get_group_install` -> `mint_install_token` depends on: - `GET /agentbinaries/install-token` with the operator session -> `200 {"token": "<non-empty>"}` (the call that 404'd before VS-60). - That token, with NO session, on `GET /api/v1/agent/binary/6?token=<token>` -> passes the auth gate. With no fetcher configured the authorized request is `404` (empty refresher slot), distinct from the `401` an unauthorized request gets, so `404`-not-`401` is the "the install token authorized the unattended fetch" signal. - Negative paths: mint without session -> `401`; download with no credentials -> `401`; download with an unknown token -> `401`; download with the operator session and no token -> authorized (browser "Download agent" button path). ## Verification beyond this test Confirmed the frontend half matches this contract on `vervain-apps` `main`: `mint_install_token` GETs `/agentbinaries/install-token`, parses `body.get("token")`, and builds the download URL `/api/v1/agent/binary/6?token=`. The only piece not exercised here is the actual Forgejo byte stream (unchanged VS-56 machinery, needs a live service-account PAT). ## CI note Lives alongside the existing `tests/*.rs` integration suite. CI runs `cargo test --lib` only by design (linking the integration-test binaries exhausts runner disk - see `check.yml`), so this is compile-checked by CI's `cargo check --all-targets` and executed by `cargo test` / `just test` locally. All 5 cases pass locally; full `just pre-commit` gate green (449 lib tests).

David added 1 commit

2026-06-26 20:57:40 +02:00

test(web): end-to-end enrollment install-token integration test

Check / fmt + clippy + build + tests (pull_request) Successful in 1m16s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

b9a9d963d5

Stands up the real router with a seeded user and session and drives the exact HTTP contract the vervain-apps "Enroll a new device" dialog depends on, proving the device-enrollment flow that VS-60 restored works end to end on the server side.

The happy path mints a token over the operator session at `GET /agentbinaries/install-token` (the call that returned `404 Not Found` before VS-60 and produced the `could not mint an agent install token` error in the dialog), asserts the `200 {"token": "<non-empty>"}` shape the frontend's `mint_install_token` deserializes, then presents that token (with NO session cookie) at `GET /api/v1/agent/binary/6?token=<token>` and asserts it passes the authorization gate. With no agent-binary fetcher configured the authorized request surfaces as `404` (empty refresher slot), which is distinct from the `401` an unauthorized request gets, so the `404` is the unambiguous "the install token authorized the unattended fetch" signal.

Negative paths assert the gate: mint without a session is `401`; the download is `401` with no credentials and `401` with an unknown token; and the operator session (no token) also authorizes the download (the browser "Download agent" button path).

Lives alongside the existing `tests/*.rs` integration suite: compile-checked by CI's `cargo check --all-targets` and run by `cargo test` / `just test` locally (CI runs `--lib` only by design, to avoid linking the heavy integration-test binaries).

#VS-60

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>