-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Cirrus CI #864
Add support for Cirrus CI #864
Conversation
Ok I've added a proper description. It's still a draft PR but please have a look. |
@theuni Care to have a look at the buildsystem stuff here? |
95035d3
to
776e30a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Looks good overall. In particular, should have the same set of tests as before.
For the Linux builds, NixOs is used
It's not NixOS but Alpine with the Nix package manager. That should also be reflected in the new files (e.g. NixOS shell
-> Nix shell
).
This sounds great but one drawback is that there is currently no way to invalidate the cache except for pushing a change to .cirrus.yml or the Dockerfile
Yeah would be nice to have this and I'm seeing you're experimenting with that in this PR.
Now after playing around with Nix, I'm not so convinced anymore:
There's an advantage of using Nix, namely you can reproduce the exact same dependencies locally by pinning the nixpkgs. When rebuilding the debian docker image you may get newer versions than in CI. Historically we didn't have problems with reproducing test failures. Either way is fine for me, but if we keep nix we should output the nixpkgs commit to actually be able to reproduce it.
I'll probably change the 32-bit i686 builds back to Debian, I had some issues with them.
i686 is only a "limitedSupportedSystem" in Nix which means that the nix cache only contains only a "minimal" package set. Best would be to either just use clang instead of clang_11 or switch to debian for i686.
Since we're on a rolling-release channel, it's rather easy to get the latest compilers for example and see miscompilations early for example.
Not sure about this, but we can try it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since I'm just noticing that Travis is still pending, I'm wondering if this PR wouldn't also be the right time to remove it.
e5c0317
to
ac702da
Compare
Concept ACK. The NixOS approach doesn't seem to add much overhead, and not too hard to replace if it's an issue. It seems Travis is acting up again, is there something left to get this to an minimal viable mergable state? |
ac702da
to
eb16650
Compare
Yes, this slipped out of my focus... I talked to a few people including @MarcoFalke and I'm considering a different approach for "bleeding edge" builds, namely regular (e.g., nightly) builds (of master) that won't get in the way of contributors working on their PRs. AFAIC this is supported by Cirrus (https://cirrus-ci.org/guide/writing-tasks/#cron-builds). Also I think that Debian experimental would be a nice platform for this, and this would then probably obsolete the last reason to NixOs, so I'm also considering switching back to Debian for the stable builds. But all of this can be done in a separate PR. Since this is currently working, let's get this merged. I've added a commit that removes Travis as suggested above. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK eb16650 mod nits
5bb5be5
to
fc5c739
Compare
fc5c739
to
e8d5d52
Compare
So long, and thanks for all fish!
e8d5d52
to
2480e55
Compare
80fb7a5
to
cc2a545
Compare
Ready for review again (when the checks pass). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK cc2a545
Argh, the "clang" builds use GCC in fact [0] because nix-shell redefines $CC. [1] There's a lot of "wrapper" stuff in general. https://nixos.wiki/wiki/C I feel all of this may be great for users but not what we want in CI, where we want a pure environment. Until now, my position was that nix doesn't really give us the benefits I hoped for but it was working, so I kept it. But now that's a real disadvantage. I think it's better to get of rid, which is somewhat sad given that I spent some time on it. [0] https://cirrus-ci.com/task/5368525575421952?command=test#L164 |
We should also consider implementing the hack from Core (cirruslabs/cirrus-ci-docs#662 (comment)) in order to run CI on the merge commit instead of the source branch (in the case of PRs). |
Summary: Switch from Travis to Cirrus as a CI for libsecp256k1. Backport of [[bitcoin-core/secp256k1#864 | secp256k1#864]] The files have been adapted to match our codebase: - The build_autotools.sh and build_cmake.sh scripts are reused from the Travis setup. - The nixos base file is removed since it would build openjdk from source for i686 and time out. This is not a good move but these files will be removed in a follow-up diff anyway, so not a big deal. - Skip JNI tests on macOS, since Java is not installed on Cirrus macOS VM. - Work around valgrind install path not being searched by CMake. This is a known CMake issue (/usr/local/include should be part of the system search path for headers): https://gitlab.kitware.com/cmake/cmake/-/issues/19120 - Increase the timeouts, since we are running each test twice the valgrind task will not complete in 1h on macOS. Test Plan: See result from my own repo: https://cirrus-ci.com/build/6029790437179392 Reviewers: #bitcoin_abc, deadalnix Reviewed By: #bitcoin_abc, deadalnix Differential Revision: https://reviews.bitcoinabc.org/D9397
Summary: Switch from Travis to Cirrus as a CI for libsecp256k1. Backport of [[bitcoin-core/secp256k1#864 | secp256k1#864]] The files have been adapted to match our codebase: - The build_autotools.sh and build_cmake.sh scripts are reused from the Travis setup. - The nixos base file is removed since it would build openjdk from source for i686 and time out. This is not a good move but these files will be removed in a follow-up diff anyway, so not a big deal. - Skip JNI tests on macOS, since Java is not installed on Cirrus macOS VM. - Work around valgrind install path not being searched by CMake. This is a known CMake issue (/usr/local/include should be part of the system search path for headers): https://gitlab.kitware.com/cmake/cmake/-/issues/19120 - Increase the timeouts, since we are running each test twice the valgrind task will not complete in 1h on macOS. Test Plan: See result from my own repo: https://cirrus-ci.com/build/6029790437179392 Reviewers: #bitcoin_abc, deadalnix Reviewed By: #bitcoin_abc, deadalnix Differential Revision: https://reviews.bitcoinabc.org/D9397
Apparently clang 15 is able to compile our cmov code into a branch, at least for fe_cmov and fe_storage_cmov. This commit makes the condition volatile in all cmov implementations (except ge but that one only calls into the fe impls). This is just a quick fix. We should still look into other methods, e.g., asm and bitcoin-core#457. We should also consider not caring about constant-time in scalar_low_impl.h We should also consider testing on very new compilers in nightly CI, see bitcoin-core#864 (comment)
…ations 4a496a3 ct: Use volatile "trick" in all fe/scalar cmov implementations (Tim Ruffing) Pull request description: Apparently clang 15 is able to compile our cmov code into a branch, at least for fe_cmov and fe_storage_cmov. This commit makes the condition volatile in all cmov implementations (except ge but that one only calls into the fe impls). This is just a quick fix. We should still look into other methods, e.g., asm and #457. We should also consider not caring about constant-time in scalar_low_impl.h We should also consider testing on very new compilers in nightly CI, see #864 (comment) ACKs for top commit: jonasnick: ACK 4a496a3 Tree-SHA512: a6010f9d752e45f01f88b804a9b27e77caf5ddf133ddcbc4235b94698bda41c9276bf588c93710e538250d1a96844bcec198ec5459e675f166ceaaa42da921d5
Apparently clang 15 is able to compile our cmov code into a branch, at least for fe_cmov and fe_storage_cmov. This commit makes the condition volatile in all cmov implementations (except ge but that one only calls into the fe impls). This is just a quick fix. We should still look into other methods, e.g., asm and #457. We should also consider not caring about constant-time in scalar_low_impl.h We should also consider testing on very new compilers in nightly CI, see bitcoin-core/secp256k1#864 (comment)
Apparently clang 15 is able to compile our cmov code into a branch, at least for fe_cmov and fe_storage_cmov. This commit makes the condition volatile in all cmov implementations (except ge but that one only calls into the fe impls). This is just a quick fix. We should still look into other methods, e.g., asm and bitcoin-core#457. We should also consider not caring about constant-time in scalar_low_impl.h We should also consider testing on very new compilers in nightly CI, see bitcoin-core#864 (comment)
On top of #862.
This PR adds Cirrus CI integration. For now this is intended to replicate the functionality that we have in Travis currently. These are a lot of builds, we should also rethink the build matrix. Moreover, the CI shell script could have some refactoring and cleaning but these issues tasks are for another PR (see also #707).
Cirrus CI is relies on Docker images for Linux builds. We make use of this extensively by building our own Docker images (with necessary packages) on which CI then runs (https://cirrus-ci.org/guide/docker-builder-vm/#dockerfile-as-a-ci-environment), see the
dockerfile
setting in.cirrus.yml
. The image is recreated for every build and then all "tasks" run on this image.For the Linux builds, NixOs is used. This is a rather uncommon choice. My intention of this is that it gives you an easy way of opening a shell on your local machine that has the build tools exactly as in the CI environment. (Just install the nix package manager on top of your distro and run the command from the
.cirrus.yml
. Now after playing around with Nix, I'm not so convinced anymore:Still, I kept Nix for now since it's working now.
Debian is already used for a s390x big-endian qemu test. I choose s390x over the more common PowerPC and others because s390x is the only officially supported big-endian port of Debian (https://www.debian.org/ports/).
On the MacOS builds, we use a forked valgrind version which support newer macOS versions (https://github.com/LouisBrunner/valgrind-macos). It's not great but it works and this was change was overdue anyway.
Todo (in this PR):
Todo (other PRs)