testserver: Standalone Greenlight testserver for non-python projects #539
Conversation
This file contains 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
Fewer demands on the environments, better managed, should make it simpler to use.
It turns out we were accessing the external `$PATH` which may or may not contain a valid `lightningd`.`
`uv` gives us more control, and fewer failure opportunities, so let's use it.
This proxy is used in the local testing environment to provide node-access to browser based clients. It strips the transport authentication, and replaces it with the payload authentication already used for the signer context.
We create a standalone service and front it with the grpc-web-proxy. Since the proxy must not rely on the payload to make decisions we just implemented a simple test proto just for this case.
14f3da8
to
ee301b7
Compare
Besides the grpc-web proxy functionality, the node grpc-web-proxy also needs the capability of locating and starting a node if it hasn't been started yet. It also needs to be configured with the correct client certificates. The `NodeHandler` class encapsulates that logic. We also test it by running a `GetInfo` call through the grpc-web-client, the node-grpc-web-proxy-, finally hitting the node, and back again.
b84c574
to
37c934d
Compare
This uses the `gl-testing` library, and builds a standalone server to test against. We currently expose four interfaces: - The scheduler interface as the main entrypoint to the service - The GRPC-Web proxy to develop browser apps and extensions against Greenlight. - The `bitcoind` interface, so you can generate blocks and confirm transactions without lengthy wait times - The node's grpc interface directly to work against a single user's node All of these will listen to random ports initially. We write a small file `metadata.json` which contains the URIs and ports for the first three, while the node's URI can be retrieved from the scheduler, since these are spawned on demand as users register.
The TLD is the root for the tree of resources we are going to spawn, so making this configurable allows us to run arbitrarily many instances on a single developer machine. This is useful if we'd like to run many tests in parallel.
37c934d
to
35aa8eb
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This uses the
gl-testinglibrary, and builds a standalone server totest against. We currently expose four interfaces:
Greenlight.
bitcoindinterface, so you can generate blocks and confirmtransactions without lengthy wait times
node
All of these will listen to random ports initially. We write a small
file
metadata.jsonwhich contains the URIs and ports for the firstthree, while the node's URI can be retrieved from the scheduler, since
these are spawned on demand as users register.
Depends #536