We weren't building the Rust plugins in the `Dockerfile` since we were
missing the dependencies. Now we do.
Changelog-Fixed: docker: The docker images are now built with the rust plugins `cln-grpc`
Mostly comments and docs: some places are actually paths, which
I have avoided changing. We may migrate them slowly, particularly
when they're user-visible.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since we're planning on standardizing on Python 3.6+ [1] I think it is a good
idea to bump our own docker image to a Debian version that fulfills that
requirement as well.
[1] https://github.com/lightningd/plugins/issues/146
Before this, docker image will never detects that
`lightning-rpc` was created if it is running in regtest
or testnet, because the file will be created under
subfolder for each network name, and entrypoint does not
check "lightning-rpc" file in those folders.
By specifying `LIGHTNINGD_NETWORK` environment var
in dockerfile, we can now check correct path.
Changelog-Added: Docker build now includes `LIGHTNINGD_NETWORK` ENV variable which defaults to "bitcoin". An user can override this (e.g. by `-e` option in `docker run`) to run docker container in regtest or testnet or any valid argument to `--network`.
Most user-contributed plugins are written in python, and not having it
available in the docker image is rather annoying to work around. So we just
add that tiny dependency to the image.
Fixes#3765
We were compiling them from source, but then not adding them in the final
docker image. This just drops the source based ones in favor of system
provided ones.
Fixes#3074
* Improved plugin install in docker
- All files generated by 'make install' are copied
- Fixes issues with incomplete installation.
- Example: New executables created by build but are missing in docker.
This was failing the docker hub builds, since the git-config retains
an absolute path to the worktree location when cloning. Copying it
over from the host system means that this path now points to a
non-existent location, which then interfered with the submodule
initialization.
This fixes it by not using the copy directly, but rather it creates a
clean clone from the copied location, including a submodule init.
Signed-off-by: Christian Decker <@cdecker>
While not strictly necessary it's certainly a good idea to test
against the latest one and not encourage users to use old versions.
Reported-by: Jonas Nick <@jonasnick>
Signed-off-by: Christian Decker <@cdecker>
This was suggested via mail: the SHA256 sums should be extracted from the
sha256sums file we are checking against, which also allows us to switch bitcoind
version at build time.
Suggested-by: Giles Hall <@vishnubob>
Signed-off-by: Christian Decker <@cdecker>
This is based on @NicolasDorier's excellent proposal for a Dockerfile, sans the
writing of a config file.
Co-authored-by: Nicolas Dorier <nicolas.dorier@gmail.com>
Co-authored-by: Christian Decker <decker.christian@gmail.com>
Signed-off-by: Christian Decker <decker.christian@gmail.com>
