AWSCredentialsProviderTest Tests Failing on armv7l build

[mike6789]

Describe the bug

Build does not complete on armv7l target with Ubuntu OS.

'''
[100%] Linking CXX executable aws-cpp-sdk-core-tests
/root/aws-sdk-cpp/tests/aws-cpp-sdk-core-tests/aws/auth/AWSCredentialsProviderTest.cpp:343: Failure
Expected equality of these values:
"goodAccessKey"
provider.GetAWSCredentials().GetAWSAccessKeyId()
Which is: ""
[ FAILED ] InstanceProfileCredentialsProviderTest.TestThatProviderRefreshes (2 ms)
/root/aws-sdk-cpp/tests/aws-cpp-sdk-core-tests/aws/auth/AWSCredentialsProviderTest.cpp:361: Failure
Expected equality of these values:
"goodAccessKey"
provider.GetAWSCredentials().GetAWSAccessKeyId()
Which is: ""
[ FAILED ] InstanceProfileCredentialsProviderTest.TestCredentialsDontRefreshForCredentialsInPast (1 ms)
/root/aws-sdk-cpp/tests/aws-cpp-sdk-core-tests/aws/auth/AWSCredentialsProviderTest.cpp:330: Failure
Expected equality of these values:
"goodAccessKey"
provider.GetAWSCredentials().GetAWSAccessKeyId()
Which is: ""
'''

Expected Behavior

Build should complete

Current Behavior

Test error out

Reproduction Steps

Simply follow the guide here -> https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/setup-linux.html

I am running this on an Orange Pi Zero board

Possible Solution

No response

Additional Information/Context

No response

AWS CPP SDK version used

main

Compiler and Version used

-- The C compiler identification is GNU 11.4.0

Operating System and version

VERSION="22.04.3 LTS (Jammy Jellyfish)"

[yasminetalby]

Hello @mike6789 ,

Thank you very much for your submission.

Based on the behavior you are experiencing:

Expected equality of these values:
"goodAccessKey"
provider.GetAWSCredentials().GetAWSAccessKeyId()
Which is: ""

as you can see in the AWSCredentialsProviderTest.cpp test file, it seems that when testing the InstanceProfileCredentialsProvider, the mockClient credentials value are not being set.

How are you providing your AWSCredentials? While looking into this, a workaround could be to disable the tests. You can do this with -DENABLE_TESTING=OFF

Best regards,

Yasmine

[mike6789]

Hi @yasminetalby ,

I actually did not provide the credentials yet, I thought this test is some kind of self-contained test with pseudo credentials. Will providing the credentials fix the test? I did disable the tests for now and was able to build.

Can you suggest a way to provide the credentials? I would like to simply make a file (such as ~/.aws/credentials) that holds my key, will the SDK pick this up or do I need to explicitly point it to this file (and how can I do that if so)?

Thank you!!

[yasminetalby]

Hello @mike6789 ,

Thank you very much for your fast response. I am glad the workaround allowed you to build the SDK. Providing your credentials will not fix the test, I wanted to check which credential provider you would like to use with the sdk.

There are multiple ways to provide the credentials to authenticate described in our developer guide (see). What you are looking for is actually documented here.

By default, the sdk will follow the default credential provider chain to retrieve credentials.

You can choose whatever option you prefer to provide credentials. If you are planning to use the shared AWS config and credentials files, the[default] profile credential values will be used by an SDK or tool operation by default if a specific named profile is not specified.

Let me know if that helps or if you need further guidance/have any questions!

Best regards,

Yasmine

[github-actions]

Greetings! It looks like this issue hasn’t been active in longer than a week. We encourage you to check if this is still an issue in the latest release. Because it has been longer than a week since the last update on this, and in the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or add an upvote to prevent automatic closure, or if the issue is already closed, please feel free to open a new one.

[asfg84]

I ran into the same issue and do not want to disable all tests to get the SDK built. Is there any way these tests can be fixed?

[flixr]

@yasminetalby can we please reopen this?
We have the same problem. The tests are selfcontained and the credentials should be injected via mock.
Works fine e.g. on amd64 and arm64, but as @mike6789 pointed out, this fails on armhf (armv7l).
Disabling all tests is not really a good solution.

[asfg84]

@yasminetalby the problem still persists with the current main. Could you please reopen this issue? We do not want to disable the tests.

[asfg84]

The problem is in the test itself, when the "Expiration" date is set to the year 2047, which causes an overflow on armhf being a 32bit architecture: e.g. https://github.com/aws/aws-sdk-cpp/blob/main/tests/aws-cpp-sdk-core-tests/aws/auth/AWSCredentialsProviderTest.cpp#L302
Thus, the credentials are reported as expired.

Changing the expiration date to the year 2037 fixes the issue (see also "Year 2038 Problem")

[jmklix]

Thanks for pointing this out. Testing your suggested change before merging the PR
#2983

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.