-
Notifications
You must be signed in to change notification settings - Fork 712
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
Run integv2 tests with nix #3824
Conversation
71f5316
to
fcf102e
Compare
This commit adds several dependacies to facilitate development.
7cdcc2c
to
56b8459
Compare
flake.nix
Outdated
# openssl_0_9_8 openssl_1_0_2 openssl_3_0 | ||
# libressl pkgs.boringssl |
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.
Is it possible to have multiple dev shells where you can select these?
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.
We do that for build, but it doesn't make as much sense here. Often if you are debugging something with openssl you'll want access to all of them. I do think that it is a little silly to have them all commented out here though. Instead I propose putting them all in the environment and creating alias so you can run all the openssls.
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.
@dougch brought up a good point: adding all the libcryptos here makes it difficult to build different versions of the library in the devShell. We might need to make different devShells for that reason alone.
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.
Good stuff. Still on the fence about including all of the various libcrypto's in the default devShell, but it does make for less work to flip between them this way. Local testing (minus offline discussion) worked on x86.
''; | ||
|
||
checkPhase = '' | ||
echo Not running tests here. Run `nix develop` to run tests. |
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.
Is this a common pattern? The checkPhase seems meant for unit tests?
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.
I found some evidence online that the checkPhase
is for flame tests. Like "is the binary actually there", "does it execute" ect... The problem with tests is that they add non-determinism in the build. The advice I got was to either 1) build the tests and install them or 2) just use the devShell. There isn't really a way to "build" and "install" the Python tests so I figured I'd cater to the developer and make it easy to build/run the tests.
There is also a non-nix reason not to build the tests in the main build. If we want to run the unit tests we have to build them. Building them means we aren't able to take advantage of LTO optimization. This PR is mostly focused on the dev shell, but one area for improvement is to make the build here match the release build as exactly as possible. See 4. on #3841
|
||
function build { | ||
banner "Running Build" | ||
javac tests/integrationv2/bin/SSLSocketClient.java |
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.
This should really be added as a target in the cmake integ test section. I'm assuming that's possible?
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.
This simply reflects what the codebuild bin script does already. Moving the Java dependency into CMakeLists.txt
is a goal but to do that idiomatically requires the use of ctests fixtures which requires at least cmake 3.7 (see here). Our minimum required cmake version is 3.0. One alternative to using fixtures is to create a script that cmake invokes (the script could handle the java compile, as well as apache setup, for the appropriate test cases).
I think this change is somewhat involved and should go in its own PR.
cmake -S . -B./build \ | ||
-DBUILD_TESTING=ON \ | ||
-DS2N_INTEG_TESTS=ON \ | ||
-DS2N_INSTALL_S2NC_S2ND=ON \ | ||
-DS2N_FAST_INTEG_TESTS=ON \ | ||
-DBUILD_SHARED_LIBS=ON \ | ||
-DCMAKE_BUILD_TYPE=RelWithDebInfo |
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.
This is fine for now but it's a bit limiting. I'm not sure if there's a better way to expose the matrix of options one might want to test, though.
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.
My intention here is to be an opinionated default. If you want to build with your own options you can invoke CMake directly. Perhaps there is a limited set of default options that invoke CMake in a few different ways. But I don't think that exposing the whole matrix of options makes sense, CMake already does that and you can use it directly for that purpose.
Waiting a re-approval from @dougch. |
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.
We'll iterate some on this in a future PR.
|
Resolved issues:
This PR adds the ability run a devShell using
nix develop
.That devShell gives you access to all the packages you need installed to run most of the integration tests, unit tests, and even clang-format the repo:
Description of changes:
This PR adds many derivations.
Call-outs:
This is only tested on x86-linux. See: #3841
Testing:
Locally -- lots of building and rebuilding. Good thing there is a cache.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.