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

Make install_shared_and_static test more robust #2179

Merged
merged 4 commits into from
Feb 13, 2025

Conversation

smittals2
Copy link
Contributor

Issues:

P198393553

Description of changes:

Making the test more robust to prevent flaky behavior:

  1. Add more logging
  2. Use sync to force file state after delete operations
  3. use --fresh with CMAKE to prevent using any cache
  4. Turn off parallel CMAKE build

Call-outs:

Point out areas that need special attention or support during the review process. Discuss architecture or design changes.

Testing:

How is this change tested (unit tests, fuzz tests, etc.)? Are there any testing steps to be verified by the reviewer?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.

@codecov-commenter
Copy link

codecov-commenter commented Feb 7, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.04%. Comparing base (6c613fa) to head (706fc6f).
Report is 23 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2179      +/-   ##
==========================================
+ Coverage   78.95%   79.04%   +0.08%     
==========================================
  Files         611      612       +1     
  Lines      105551   106065     +514     
  Branches    14950    14985      +35     
==========================================
+ Hits        83341    83835     +494     
- Misses      21558    21578      +20     
  Partials      652      652              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@smittals2 smittals2 marked this pull request as ready for review February 8, 2025 00:30
@smittals2 smittals2 requested a review from a team as a code owner February 8, 2025 00:30
samuel40791765
samuel40791765 previously approved these changes Feb 11, 2025
@@ -6,7 +6,7 @@ set -exo pipefail

source tests/ci/common_posix_setup.sh

export CMAKE_BUILD_PARALLEL_LEVEL=${NUM_CPU_THREADS}
export CMAKE_BUILD_PARALLEL_LEVEL=1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great find, were most of the random CI failures due to race conditions with the CMake building or the invalid file states? Seems like the latter's more of the cause of our issues, but I could be wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsure what the CI failures were because of but my hypothesis is the main culprit is this parallelism. I wasn't able to reproduce the issues.

The other file state stuff and using --fresh is to be more explicit about our expectations of state during the execution.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think --fresh and the file state issues you've discovered seem more like the culprit. CMake parallelism's generally relatively harmless (ninja uses multiple threads by default and make -j(threads) is often used to speed things up).
But nothing to get too fixated over here, this build test is fairly small and fast already.

${CMAKE_COMMAND} -H${AWS_LC_DIR} -B${BUILD_DIR} -GNinja -DCMAKE_INSTALL_PREFIX=${INSTALL_DIR} -DBUILD_TESTING=OFF -D${BUILD_SHARED_LIBS}
sync

${CMAKE_COMMAND} --fresh -H${AWS_LC_DIR} -B${BUILD_DIR} -GNinja -DCMAKE_INSTALL_PREFIX=${INSTALL_DIR} -DBUILD_TESTING=OFF -D${BUILD_SHARED_LIBS}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does --fresh behave any differently than removing the entire build folder on line 44?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's about having an explicit instruction to cmake to prevent any old cached stuff from being used. Removing the build folder likely takes care of this, but it doesn't hurt to be explicit here. Especially to safeguard against any future changes that might change this expectation

@smittals2 smittals2 enabled auto-merge (squash) February 12, 2025 23:24
@@ -6,7 +6,7 @@ set -exo pipefail

source tests/ci/common_posix_setup.sh

export CMAKE_BUILD_PARALLEL_LEVEL=${NUM_CPU_THREADS}
export CMAKE_BUILD_PARALLEL_LEVEL=1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think --fresh and the file state issues you've discovered seem more like the culprit. CMake parallelism's generally relatively harmless (ninja uses multiple threads by default and make -j(threads) is often used to speed things up).
But nothing to get too fixated over here, this build test is fairly small and fast already.

@smittals2 smittals2 merged commit bd09b3a into aws:main Feb 13, 2025
115 of 119 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants