Nothing automatic ran either e2e suite, so every browser-level guarantee in this wallet -- WebAssembly under the shipped CSP, the recovery-phrase and private-key DOM wipes, the ConfirmTx spend gate, the dApp approval round trips -- held only when a human or an agent remembered to run it by hand. .gitea/workflows/e2e.yml adds two jobs, e2e-chrome and e2e-firefox, one per browser so a Chrome failure cannot hide the Firefox result. They are separate from the check workflow: REPO_POLICIES.md caps make test at 20 seconds and script/cibuild is a docker build whose Dockerfile runs make check, so neither the cap nor the local fast path is touched. make check is byte-for-byte unchanged. Neither suite could run on the runner as it stood, and the reason is not docker-in-docker. The runner executes a job inside a container against the HOST's docker daemon, and the job's checkout lives on a docker volume rather than a host path, so `docker run -v "$PWD:/work"` is resolved by the host, silently succeeds and mounts an empty directory -- measured on this runner. The runner image's node is also too old to install this repo's dependencies. Both suites therefore ship the repo to the daemon as a build context and build the extension inside the pinned image, which leaves docker as the only prerequisite on a runner or a laptop. The suites themselves are unchanged; only how the repo reaches the container is. Both scripts now build with --iidfile and run the image by ID rather than by tag, so two clones running a suite at once on the same host cannot swap it under each other. The jobs report, they do not gate. Whether a check blocks a merge is Gitea branch protection, which this repo does not configure, so a failure is a red mark a reviewer must account for. Nothing can pass vacuously: no continue-on-error, no `|| true`, and both scripts exit non-zero when docker is missing, when the image build fails and when the browser fails to start.
2.8 KiB
Executable File
2.8 KiB
Executable File