ci.yml is a standing red — prepares against upstream lnbits + poetry, can't import the aiolabs bunker surface #24

New issue

Open

opened 2026-06-18 17:08:14 +00:00 by padreug · 0 comments

padreug commented

2026-06-18 17:08:14 +00:00

Owner

Problem

.github/workflows/ci.yml is the stock upstream lnbits-extension CI template. It does not fit this aiolabs fork:

Wrong lnbits. It prepares with lnbits/lnbits/.github/actions/prepare@dev and lints via lnbits/lnbits/.github/workflows/lint.yml@dev — i.e. upstream github.com/lnbits/lnbits, which has none of the aiolabs bunker surface spirekeeper imports at module top: lnbits.core.services.nsec_bunker (NsecBunkerAdminClient, npub_to_hex, revoke_key_user, …) and lnbits.core.signers.remote_bunker.ensure_policy.
Wrong toolchain. It runs poetry run pytest, but the repo's actual flow is uv + the regtest container (/app/.venv/bin/python -m pytest against an aiolabs-lnbits mount). poetry isn't part of the dev setup.

Symptom

Any module importing the aiolabs bunker APIs (e.g. pairing.py) fails to import under upstream lnbits → the whole pytest session errors at collection → CI red. The lint.yml@dev upstream-lnbits lint job is similarly mismatched.

Confirmed standing red, providing zero signal:

#21 final commit 9c5f07c → ci.yml failure (merged anyway)
#23 head a5efdf2 → ci.yml failure

…while the real suite is green (210 passed) in the regtest container against aiolabs/lnbits. Reviewers currently have to know to ignore the red.

Fix options (pick one)

Point prepare/lint at aiolabs/lnbits instead of lnbits/lnbits, pinned to a commit ≥ the #55 merge (b5fba561) — the version spirekeeper now hard-requires. Needs the Forgejo Actions runner able to fetch git.atitlan.io/aiolabs/lnbits.
Mirror the regtest flow: build/install lnbits from aiolabs/lnbits + run pytest via uv (drop poetry), matching how the suite is actually run.
Interim: install aiolabs/lnbits as a test dep and switch custom-pytest to uv.

Whichever path, pin the lnbits version to ≥ #55 so it tracks the runtime requirement spirekeeper main carries.

aiolabs/lnbits#55 (the bunker APIs spirekeeper requires), #21 / #23 (pairing).
This is fork-wide hygiene: the same template CI ships in other aio extension forks and has the same mismatch wherever they touch fork-only lnbits APIs.

## Problem `.github/workflows/ci.yml` is the stock upstream lnbits-extension CI template. It does not fit this aiolabs fork: 1. **Wrong lnbits.** It prepares with `lnbits/lnbits/.github/actions/prepare@dev` and lints via `lnbits/lnbits/.github/workflows/lint.yml@dev` — i.e. **upstream** `github.com/lnbits/lnbits`, which has none of the aiolabs bunker surface spirekeeper imports at module top: `lnbits.core.services.nsec_bunker` (`NsecBunkerAdminClient`, `npub_to_hex`, `revoke_key_user`, …) and `lnbits.core.signers.remote_bunker.ensure_policy`. 2. **Wrong toolchain.** It runs `poetry run pytest`, but the repo's actual flow is `uv` + the regtest container (`/app/.venv/bin/python -m pytest` against an aiolabs-lnbits mount). `poetry` isn't part of the dev setup. ## Symptom Any module importing the aiolabs bunker APIs (e.g. `pairing.py`) fails to import under upstream lnbits → the whole pytest session errors at collection → CI red. The `lint.yml@dev` upstream-lnbits lint job is similarly mismatched. Confirmed standing red, providing **zero signal**: - `#21` final commit `9c5f07c` → `ci.yml` **failure** (merged anyway) - `#23` head `a5efdf2` → `ci.yml` **failure** …while the real suite is green (210 passed) in the regtest container against `aiolabs/lnbits`. Reviewers currently have to *know* to ignore the red. ## Fix options (pick one) - **Point prepare/lint at `aiolabs/lnbits`** instead of `lnbits/lnbits`, pinned to a commit ≥ the #55 merge (`b5fba561`) — the version spirekeeper now hard-requires. Needs the Forgejo Actions runner able to fetch `git.atitlan.io/aiolabs/lnbits`. - **Mirror the regtest flow**: build/install lnbits from `aiolabs/lnbits` + run pytest via `uv` (drop poetry), matching how the suite is actually run. - **Interim**: install `aiolabs/lnbits` as a test dep and switch `custom-pytest` to uv. Whichever path, pin the lnbits version to ≥ #55 so it tracks the runtime requirement spirekeeper main carries. ## Related - `aiolabs/lnbits#55` (the bunker APIs spirekeeper requires), `#21` / `#23` (pairing). - This is fork-wide hygiene: the same template CI ships in other aio extension forks and has the same mismatch wherever they touch fork-only lnbits APIs.

padreug referenced this issue

2026-06-18 17:24:42 +00:00

feat(ui): Fleet Pair / Revoke spire UI (#9/#12) #25

padreug referenced this issue

2026-06-18 17:28:06 +00:00

feat(pairing): authorize kind-22242 (NIP-42 AUTH) in spire policy (#52) #26

padreug referenced this issue from a commit

2026-06-19 21:23:14 +00:00

docs(pairing): TTL + token-revoke now enforced post-bind (nsecbunkerd#27)