azure-sdk-for-cpp: Storage CI/CD tests failing
CI/CD is blocked because storage tests are failing:
Test command: /home/vsts/work/1/s/build/sdk/storage/test/azure-storage-test
2: Test timeout computed to be: 10000000
2: [==========] Running 17 tests from 5 test suites.
2: [----------] Global test environment set-up.
2: [----------] 1 test from BlobServiceClientTest
2: [ RUN ] BlobServiceClientTest.ListContainers
2: unknown file: Failure
2: C++ exception with description "basic_string::_M_construct null not valid" thrown in the test fixture's constructor.
2: [ FAILED ] BlobServiceClientTest.ListContainers (0 ms)
2: [----------] 1 test from BlobServiceClientTest (0 ms total)
2:
2: [----------] 4 tests from BlobContainerClientTest
2: unknown file: Failure
2: C++ exception with description "basic_string::_M_construct null not valid" thrown in SetUpTestSuite().
2: [ RUN ] BlobContainerClientTest.CreateDelete
2: unknown file: Failure
2: C++ exception with description "basic_string::_M_construct null not valid" thrown in the test body.
2: [ FAILED ] BlobContainerClientTest.CreateDelete (0 ms)
2: [ RUN ] BlobContainerClientTest.Metadata
1/1 Test #2: azure-storage-test ...............***Exception: SegFault 0.15 sec
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 0.22 sec
The following tests FAILED:
2 - azure-storage-test (SEGFAULT)
Errors while running CTest
I have to comment out the test to unblock my and @vhvb1989’s PRs.
I think it is in BlobServiceClientTest’s constructor. Null connection string gets returned, and it fails. I could’ve safeguard the code from null cstr myself, but I think it won’t go much further. It looks like it expects connection string being set as an environment variable, and when it is not set on the CI/CD machine, it won’t be able to go much further, i.e. the test would still fail, it looks like.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 15 (15 by maintainers)
@antkmsft Yes, I totally agree that we should work together to improve this.
I want to clarify that Storage test cases were able to build and run in the past, but then Core SDK introduced some breaking changes and Storage test cases didn’t work anymore. Even before storage team was able to fix the build error, those breaking changes was merged into master, with some bugs in it. Then up until now, storage team are never able to fix the CI because those bugs are not in storage code, they’re in Core code.
Then about the dependency issue, I think it would be best for no matter ourselves as developers or our customers to install dependencies in the same way. I didn’t see any essential difference between libxml2 and libcurl as external dependencies. So if you install libcurl via vcpkg, it would also work to install libxml2 via vcpkg. If you install libcurl from source, it also works to install libxml2 from source. I agree with you that we should add some instructions about how to install dependencies. Is there any instructions or readme about how to install libcurl that we can refer to when writing instructions of how to install libxml2?
Right now, i’m also okay if you want to disable all storage test cases to get CI pass. We’re going to fix them all and add them back after all bugs in Core SDK are fixed. But I still think it’s necessary for us to think about how to handle situations like this in the future. I mean sooner or later, there’s going to be another breaking change in Core SDK, and when we have many many services, most of which (if not all) depend on Core SDK, all those services will be broken.