Integrating VLS option on tests #8917
Integrating VLS option on tests #8917enaples wants to merge 25 commits intoElementsProject:masterfrom
Conversation
…stead of having an all-or-nothing logic for all nodes created by `node_factory`
hard-conding the socket binary path before instantiating the vls class instance is not ideal
…e` wants a string
|
On because some error on vls-side. I report logs for convenience: |
|
WHAT SHOULD BE TAKEN INTO ACCOUNTHaving |
…stead of having an all-or-nothing logic for all nodes created by `node_factory`
hard-conding the socket binary path before instantiating the vls class instance is not ideal
…e` wants a string
Adding more test cases
Good catch, that we can only run a single node using the vls signer. However if we do not set the envvar, and set it in the proc.env field we can give each node their own signer. So don't set the envvar, set the proc.env as you spawn the signer in start() and it should wire things up correctly. For reference: |
Important
26.04 FREEZE March 11th: Non-bugfix PRs not ready by this date will wait for 26.06.
RC1 is scheduled on March 23rd
The final release is scheduled for April 15th.
Checklist
Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:
tools/lightning-downgradeRefactoring fixtures to test VLS implementation
The goal is to integrate VLS testing into the CLN test suite in a way that is self-contained — no changes to the
pyln-testinglibrary — and flexible enough to test different VLS implementations at different stages (different repos or commits) against the current CLN version, taking inspiration fromtools/reckless.The core idea is that
ValidatingLightningSignerDshould be generic: driven by the repos variable and optionally a target commit, it clones, builds and manages any conforming signer implementation. The fixture layer then decides which nodes use it and which implementation to test (so far only this is supported).