Create nightly CI process that tests against CLN master, use CLN latest release binary for "on push" diff CI testing

[cdecker]

We want to test against a recent version to get tipped off when deprecations hit us, but the release is new enough, no need to waste CI cycles rebuilding CLN master over and over again.

❯ curl -s https://api.github.com/repos/ElementsProject/lightning/releases/latest | jq '.assets[] | select(.name | contains("22.04")) | .browser_download_url'

The above snippet will get us the latest download URL for Ubuntu 22.04.

[chrisguida]

This seems better, yeah :)

[chrisguida]

Do we still want to test master nightly to alert us of upcoming breakages? I liked your idea of doing a "diff CI" for pushes, and a "full CI" nightly.

[chrisguida]

We want two different test processes:

1. every push, we test against only what changed, and we pull CLN latest release binary for these tests.
2. every night, we build CLN master and check all plugin code against this, to see if anything upstream broke.

Side note: If stuff breaks on master, we have time to notify plugin maintainers that their plugins are broken and they need to fix before the upcoming CLN release. Once the new release is out, if plugins still aren't fixed, we move them to archive.

[chrisguida]

We also want to move to a system where all plugins are built from source every night, and we also want to enforce that all plugins have tests, ideally useful tests.

But this can be a separate issue.

[chrisguida]

I don't know how to get @fmhoeger to appear in the list of assignees, so i'm assigning myself.

[fmhoeger]

1. every push, we test against only what changed, and we pull CLN latest release binary for these tests.

Would it make sense to modify above line to read:

1. for every push in the context of a PR, we test against only what changed, and we pull CLN latest release binary for these tests.

[chrisguida]

Sure, that sounds good.