joinmarket-clientserver
joinmarket-clientserver copied to clipboard
JoinMarket-Org
GitHub workflow update (Python and Bitcoin Core versions)
- Remove Python 3.6 (EOL), add Python 3.10.
- Add support for testing against multiple Bitcoin Core versions, add 0.18.0 (oldest officially support for test suite) and 22.0 (latest stable release). Previously we tested against hardcoded 0.19.1. IMO testing against oldest supported and latest makes sense, if tests pass on both, they should pass on releases inbetween too, unless there is some behaviour affecting us changed twice.
Also changed Core downloads from bitcoin.org to bitcoincore.org.
For now, opening PR as a test and for discussion. Will increase running time 2x.
Another thing we don't test is aarch64 (arm64). That would also double number of checks, but no point even trying that right now as ARM tests are currently broken.
Will increase running time 2x.
Actually not, as they run in parallel. Question is - what limits do we have here? I have no idea.
Will increase running time 2x.
Actually not, as they run in parallel. Question is - what limits do we have here? I have no idea.
Yeah I'm really uncertain about what's going on here. Builds in parallel, sure, but still .. compute cost? Also, is caching somehow applied? I somehow got that impression a while back, because I saw some CI test runs finish really quickly, whereas on my machine (which is fairly high end), it was taking 14 minutes or so. I guess caching could work if: there are no edits to jmdaemon then maybe it doesn't run the tests in there? I guess that should make sense with well designed tests - the tests should test specifically and only the contents of the package, and any external dependencies should be somehow mocked. But I don't know the dividing line between theory and practice there.
Certainly if we started thinking about all the different configurations in which you could run this application, there would be an exponential blowup in the number of test runs.
We should probably using mocking more aggressively than we do in our tests ... or should we? - that would just stop us observing how our code fails to run with Bitcoin Core version XX - the RPC interface to Core is a moving target.
I guess that's just part of the whole integration/e2e testing vs unit testing thing. We need both.
It looks there are 2000 free CI/CD minutes, so don't think there is a problem with this change (testing with oldest supported and most recent Bitcoin Core and supported Python versions).
Updated Bitcoin Core from 22.0 to 23.0.
We could also add macos-latest in addition to ubuntu-latest, with some small changes. I recently did that for my bitcoin-scripts project. See https://github.com/kristapsk/bitcoin-scripts/commit/2eedf0a675383073a5ad01e6e0bbf5b8f5d1851e.
@kristapsk I guess you are waiting for an ACK on this, only? I would leave this to your discretion, if you think it is a net positive for the CI, then please go ahead. I see nothing wrong in the script,so:
ACK https://github.com/JoinMarket-Org/joinmarket-clientserver/commit/c92120619e48ac79708b020bd702fe1441090017
@kristapsk I guess you are waiting for an ACK on this, only? I would leave this to your discretion, if you think it is a net positive for the CI, then please go ahead. I see nothing wrong in the script,so:
ACK c921206
Yes, was waiting for a Concept ACK, don't see downsides here.