This workflow has never had a particularly good signal-to-noise ratio,
and disabling it saves us a couple of GH Actions cycles, with only
minor reduction in test reach. We should rather rethink this and use
the installation instructions to write Dockerfiles for each described
architecture, and then have the CI test-build those Dockerfiles. That
would also cover the docs during testing, rather than having yet another
place where the instructions can bitrot away.
Changelog-None No user-visible change.
Tacking the fuzz testing onto the PR testing not a good idea. It
causes completely unrelated tests to fail, and doesn't guarantee it
will find newly introduced ones. Running daily is likely better.
Changelog-None No user visible change
Turns out that if we publish from PRs we may end up with versioning
collisions, causing errors. This publishes only from `master` where we
have a linearizable history, and should therefore get unique versions.
Changelog-None
We are tracking the flakiness of tests [here][1], so no need to suffer
through fail-looping CI while trying to fix a PR or get it merged.
Changelog-None
[1]: http://35.239.136.52:3170/run
We used to run the publication on each PR, which could cause conflicts
due to the naming convention being based on the commit history length,
and multiple PRs potentially hitting the same name.
Adding a `workflow_dispatch` trigger allows us to still test the
workflow in PRs but only do so manually (when we're watching anyway).
Changelog-None
Code using `CI_SERVER` was added recently to track something. It
attempts to short-cut if `CI_SERVER` is not set, but on gitlab it
is set to `yes`. https://docs.gitlab.com/ee/ci/variables/
Instead use `CI_SERVER_URL`, maybe that is what is intended?
We were accidentally testing against `bitcoind` rather than
`elementsd` which meant we believed everything was find, when in
reality some tests broke. By only installing the required daemon we
ensure that such a mixup causes a CI failure.
If you previously configured with `--enable-developer` we turn that into `--enable-debugbuild`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Removed: build: `--enable-developer` arg to configure (and DEVELOPER variables): use `./configure --enable-debugbuild` and `developer` setting at runtime.
We use this file as a proxy for breaking changes in the signer
protocol. It may not catch all the breaking changes, but it's a
good first approximation.
Update the lightningd <-> channeld interface with lots of new commands to needed to facilitate spicing.
Implement the channeld splicing protocol leveraging the interactivetx protocol.
Implement lightningd’s channel_control to support channeld in its splicing efforts.
Changelog-Added: Added the features to enable splicing & resizing of active channels.
GH was complaining about Node v12 being used in v2.2.4. We used to
hold back from this upgrade because v3 was breaking quotas, but we
should try again.
The lnprototest occasionally fails on our CI due to the
timeout duration we set while waiting for cln to start up.
This timeout is insufficient for machines like the ones
used in the GitHub CI environment.
To address this issue, this commit introduces the use of
environment variables to increase the lnprototest timeout,
ensuring sufficient time for cln to initialize.
Changelog-None
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
With the exception of fuzzing, make all builds in the `compile` job,
and simply download them in the other steps.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We used to have to use environment variables to pass through to
github/scripts/build.sh, but now we run ./configure directly it's
clearer to use explicit flags (though some matrixes still use env vars
for simplicity).
We also don't need to set COMPAT, as it's the default (MacOS tests
that we build without it, but otherwise we assume it's on).
And we make `gather` actually depend on all the other steps!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
