Skip to content

test: allow the e2e backend host to be set at launch - #680

Draft
mdozhdev wants to merge 1 commit into
synonymdev:masterfrom
mdozhdev:test/e2e-remote-backend-host
Draft

test: allow the e2e backend host to be set at launch#680
mdozhdev wants to merge 1 commit into
synonymdev:masterfrom
mdozhdev:test/e2e-remote-backend-host

Conversation

@mdozhdev

Copy link
Copy Markdown

Description

e2e-tests-local needs Docker and the iOS Simulator on the same machine, which GitHub-hosted macOS runners cannot provide — Apple's Virtualization framework has no nested virtualization for macOS guests. That is why the job runs on a self-hosted Mac, and why it runs as a single shard at ~2h per run.

This adds a parallel workflow that keeps the Simulator on a hosted runner and puts the regtest stack on a short-lived GCP VM.

e2e-tests.yml is untouched. The self-hosted path keeps working exactly as now. The new workflow is workflow_dispatch only, so both can run against the same PRs until this one is trusted, and rollback is deleting one file.

Env.swift (1 line)

-        infoPlistValue("E2E_LOCAL_HOST") ?? "127.0.0.1"
+        configValue("E2E_LOCAL_HOST") ?? "127.0.0.1"

e2eLocalHost read only from Info.plist, which is written when the app is compiled. A run against a remote stack does not know the address until it has provisioned one — after the build. Rebuilding per run is not viable on macOS.

configValue is the existing helper directly above it, resolving env var → launch argument → Info.plist. Because it falls through to the same lookup, builds that set nothing behave identically; it only adds a way to override at launch.

It is reachable only from isE2E, which requires the E2E_BUILD compilation flag. That flag appears in no project file, no scheme and no default — only in e2e build commands. A release build never compiles that branch.

Status

Draft — the workflow has not been run end to end yet. It depends on synonymdev/bitkit-e2e-tests#204 being merged (it references those actions at @main) and on a configured GCP project.

Verified so far, on a GitHub-hosted macOS runner: VM provisioned, stack reached, credentials fetched, and a request from inside a booted Simulator recorded in the VM's own access log. What remains unproven is a real suite run.

Configuration needed

vars.REGTEST_GCP_PROJECT
secrets.REGTEST_WIF_PROVIDER
secrets.REGTEST_SERVICE_ACCOUNT

Produced by ci/regtest-vm/setup-wif.sh in bitkit-e2e-tests. Without them the new workflow simply cannot be dispatched; nothing else is affected.

Linked Issues/Tasks

Screenshot / Video

n/a — CI only.

e2eLocalHost read only from Info.plist, which is written when the app is
compiled. A run against a stack on another machine does not know the
address until it has provisioned one, after the build. Rebuilding per run
is not viable on macOS.

configValue is the existing helper directly above, resolving env var,
then launch argument, then Info.plist. Falling through to the same lookup
means builds that set nothing are unaffected; it only adds a way to
override at launch, which is how the test runner supplies the address.

Reachable only from isE2E, which requires the E2E_BUILD compilation flag
that no project file sets and only e2e build commands pass, so a release
build never compiles that branch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@mdozhdev
mdozhdev force-pushed the test/e2e-remote-backend-host branch from 8ecc725 to 03aaf1f Compare August 21, 2026 19:37
@mdozhdev mdozhdev changed the title test: add an e2e workflow that runs the stack on a remote VM test: allow the e2e backend host to be set at launch Aug 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant