Skip to content
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

Merged
merged 16 commits into from
Feb 27, 2023
Merged

Conversation

harrisonkaiser
Copy link
Contributor

@harrisonkaiser harrisonkaiser commented Feb 11, 2023

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:

$ nix develop
...
[in-dev-shell] $ configure
<runs-cmake-configure-stage>...

[in-dev-shell] $ build
<runs-cmake-build-stage>...

[in-dev-shell] $ integ happy
<runs-happy-path-integ-test>...

[in-dev-shell] $ unit
<runs-all-unit-tests>...

[in-dev-shell] $ check-clang-format
<running clang-format checks>...

[in-dev-shell] $ do-clang-format
<running clang-format in place>...

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.

This commit adds several dependacies to facilitate
development.
@harrisonkaiser harrisonkaiser marked this pull request as ready for review February 20, 2023 16:19
@harrisonkaiser harrisonkaiser mentioned this pull request Feb 20, 2023
14 tasks
nix/openssl_1_0_2_fips.nix Outdated Show resolved Hide resolved
nix/gnutls.nix Outdated Show resolved Hide resolved
flake.nix Show resolved Hide resolved
flake.nix Outdated
Comment on lines 176 to 177
# openssl_0_9_8 openssl_1_0_2 openssl_3_0
# libressl pkgs.boringssl
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

flake.nix Outdated Show resolved Hide resolved
CMakeLists.txt Outdated Show resolved Hide resolved
Copy link
Contributor

@dougch dougch left a 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.
Copy link
Contributor

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?

Copy link
Contributor Author

@harrisonkaiser harrisonkaiser Feb 22, 2023

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

@dougch dougch self-requested a review February 22, 2023 22:49
.gitignore Outdated Show resolved Hide resolved
nix/amazon-corretto-8.nix Outdated Show resolved Hide resolved

function build {
banner "Running Build"
javac tests/integrationv2/bin/SSLSocketClient.java
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Comment on lines +15 to +21
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
Copy link
Contributor

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.

Copy link
Contributor Author

@harrisonkaiser harrisonkaiser Feb 24, 2023

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.

@harrisonkaiser
Copy link
Contributor Author

Waiting a re-approval from @dougch.

Copy link
Contributor

@dougch dougch left a 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.

@harrisonkaiser harrisonkaiser merged commit 6d4eb1f into aws:main Feb 27, 2023
@harrisonkaiser
Copy link
Contributor Author

We'll iterate some on this in a future PR.

#3841

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants