feat: lifecycle CI tests real production join flow - #44
Merged
Conversation
After provider-platform's multi-PP refactor, the e2e flow needs a PP record and council_membership row in the DB before the executor can resolve channels. The setup container writes the PP secret + membership data to /config/seed.json; the provider entrypoint encrypts the SK with SERVICE_AUTH_SECRET and inserts both rows before starting the server.
Lifecycle now spins up a council-platform service alongside
provider-platform and walks through the full user-driven flow:
1. Admin authenticates to council-platform (wallet challenge → JWT)
2. Admin creates a council via PUT /council/metadata
3. Admin adds the channel via POST /council/channels
4. PP operator authenticates to provider-platform dashboard
5. PP operator registers a PP via POST /dashboard/pp/register
6. PP operator signs a join envelope and submits via
POST /dashboard/council/join (forwarded to council-platform)
7. Admin lists join requests and approves
8. Admin calls on-chain add_provider
9. Provider-platform's event watcher activates the membership
10. Bundle flow runs (deposit / send / withdraw)
11. Remove provider — pinned (API not implemented yet)
Two distinct identities — admin (council deployer + admin) and
pp_operator — mirror real production usage. No DB seeding,
no env-var fixtures: every state change goes through an HTTP API.
Compose adds a council-db (separate Postgres) and council service.
The reusable lifecycle workflow gains a council_image_override
input matching the existing provider_image_override, so council
PRs can run lifecycle tests against their own pr-<sha> image.
AquiGorka
added a commit
that referenced
this pull request
Jul 29, 2026
## Why The invite-gate failure on moonlight-pay PR #44 (run [30389517406](https://github.com/Moonlight-Protocol/moonlight-pay/actions/runs/30389517406)) was not a stellar-sdk 16 browser regression. The moonlight-pay container log shows the actual error: > Could not find version of '@moonlight/moonlight-sdk' that matches specified version constraint '^0.13.0'. A newer matching version was found, but it was not used because it was newer than the specified minimum dependency date of 2026-07-27 19:42 UTC jsr @moonlight/moonlight-sdk 0.13.0 was published 2026-07-28 17:43 UTC, 1h54m before the run. The frontend services run `denoland/deno:latest`, which now resolves to 2.9.x where Deno's minimum dependency age policy (default 24h) is enforced at `deno install` and at esbuild deno-loader resolution, even with a committed deno.lock in the container. The build failed, the container served without a fresh bundle, and `#connect-btn` never rendered. The consoles passed only because their deps are all older than 24h. The backend services already pin `denoland/deno:2.7.9` and the repo CI workflows pin Deno v2.7.x, which is why the same moonlight-pay commit was green in Tests and Deploy. No repo in the org configures min-dep-age anywhere; the floating tag silently changed CI resolution behavior when `:latest` rolled forward. ## What Pin every `denoland/deno:latest` to `denoland/deno:2.7.9` (21 occurrences, 11 compose files: e2e, otel, governance, invite-gate, pos-instant, playwright, lifecycle, multi-asset suites plus the e2e/, lifecycle/, multi-asset/ standalone files). No other changes. Without this, every suite here fails on any bump PR opened within 24h of a JSR publish.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two CI fixes shipped together because both depend on the council-platform PR landing first:
1. e2e CI seeds PP + membership in provider DB
After provider-platform's multi-PP refactor, the e2e flow needs a PP record and council_membership row in the DB before the executor can resolve channels. The setup container writes the PP secret + membership data to `/config/seed.json`; the provider entrypoint encrypts the SK with `SERVICE_AUTH_SECRET` and inserts both rows before starting the server.
2. Lifecycle CI tests the full real production join flow
Lifecycle now spins up a council-platform service alongside provider-platform and walks through the full user-driven flow with two distinct identities (admin + pp_operator):
No DB seeding, no env-var fixtures: every state change goes through an HTTP API.
The reusable lifecycle workflow gains a `council_image_override` input matching the existing `provider_image_override`, so council-platform PRs can run lifecycle tests against their own `pr-` image.
Test plan
Merge dependency
Requires Moonlight-Protocol/council-platform#10 to merge first so the published `council-platform:latest` image contains the per-council infrastructure that the lifecycle test depends on.