Cln version manager #380
Cln version manager #380
Conversation
ErikDeSmedt
force-pushed
the
cln_version_manager
branch
10 times, most recently
from
13f76fe to
6f1f298
Compare
|
This PR is ready for review. It includes
It doesn't include
These changes will follow later in a separate PR |
|
Pipelines will execute successfully once I've pulished |
ErikDeSmedt
force-pushed
the
cln_version_manager
branch
3 times, most recently
from
b2972f3 to
7f1a44c
Compare
|
This branch introduce To test it you can use I did not modify |
ErikDeSmedt
force-pushed
the
cln_version_manager
branch
from
7f1a44c to
25cfb2b
Compare
|
I didn't test this yet (on my phone) but aside from a very minor typo ( |
| assert not request_mock.get.called | ||
|
|
||
| # get them again using force to ensure we do download them | ||
| vm.get_all(force=True) |
There was a problem hiding this comment.
This can probably be moved within the with so assert request_mock.get.called can be called to verify the force flag was respected
There was a problem hiding this comment.
Setting this up is more a bit more annoying.
Mocking requests.get requires to return a valid request object which returns a 200 - status code and a working lightningd-release in the payload.
I'd prefer not to waste a few hours in creating this test.
There was a problem hiding this comment.
With no assertions to show vm.get_all(force=True)actually downloads the versions when the directory already exists, I say we remove it from the test to reduce test times
There was a problem hiding this comment.
That is probably a better idea.
ErikDeSmedt
force-pushed
the
cln_version_manager
branch
2 times, most recently
from
215e6bf to
1392579
Compare
|
Testing this out it seems eerily quiet. It looks like we need to configure the |
Question: Are you on very crappy internet and is the download of When I do I prefer to not route all logging through |
Indeed that'll be the issue, hotel speeds from the analog times I guess 😉 |
We do `poetry install` here. This ensures that `clnvm` is installed and can be used in the container
Co-authored-by: Randy808 <[email protected]>
`merge_group` instead of `merge_roup` Co-Authored-By: Christian Decker <@cdecker>
When a user requests a path to lightningd they might want - to run the executable. The user would need `node_version.lightningd` which contains the full path to the executable - to add the executable to the path. The user would need `node_version.bin_path` which contains the path to the folder containing `lightningd`. - to create a symlink to a known place. The user would need `node_version.root_path` which is at the root of the release. Typically, `root_path/usr/local/bin/lightningd` contains the executable. This commit handles all these cases more explicitly. I've also edited `gl-testing` to use the `lightningd`-field instead.
This ensures that users who pip install the package get working type-hints
Adding `gprcio-tools` as a dependency ensures `poetry install` works. Adding `cln-version-manager` as a dev-dependency ensures `poetry install` works and that we use an editable install
Dropping the lines make tests faster. We don't lose much coverage. We aren't even asserting that setting force to true has the desired effect
cdecker
force-pushed
the
cln_version_manager
branch
from
0deddb0 to
57ae9b9
Compare
I've introduced
cln_version_manager.It is currently very hard to run
gl-testingin standalone-mode.One of the dependencies of
gl-testingare a wide range of Core Lightning versions.These files are packaged into the docker-file.
I've adapted the
gl-testingpython-module to download the Core Lightning binaries for the user.It will download them to
XDG_CACHE_DIRby default but users can configure their folder.