plugins
plugins copied to clipboard
lightningd
Create nightly CI process that tests against CLN master, use CLN latest release binary for "on push" diff CI testing
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.
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.
We want two different test processes:
- every push, we test against only what changed, and we pull CLN latest release binary for these tests.
- 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.
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.
I don't know how to get @fmhoeger to appear in the list of assignees, so i'm assigning myself.
- 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:
- 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.
Pretty sure this was solved by @daywalker90 in various PRs and @sip-21 in June and July.
Most notably this one https://github.com/lightningd/plugins/pull/497
And this one https://github.com/lightningd/plugins/pull/537
Closing.