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

Travis CI doesn't like our LambdoraLdpIT integration tests #64

Open
tdonohue opened this issue Nov 10, 2017 · 4 comments
Open

Travis CI doesn't like our LambdoraLdpIT integration tests #64

tdonohue opened this issue Nov 10, 2017 · 4 comments

Comments

@tdonohue
Copy link
Member

tdonohue commented Nov 10, 2017

Found via #63

Travis seems to not like our LambdoraLdpIT integration test class. The master branch fails in Travis, see: https://travis-ci.org/duraspace/lambdora/builds/300342798

I recall that, when LambdoraLdpIT was added in PR #44, @awoods noted he seemed to see local test failures as well. I'm now starting to wonder if Travis is having that same issue.

However, locally, all tests succeed for me. This may be an environmental or OS specific issue.

@tdonohue
Copy link
Member Author

I was able to reproduce these errors by attempting a fresh ./gradlew build on an Ubuntu 16.04 Virtual Machine. So, it seems to be likely OS specific.

@tdonohue
Copy link
Member Author

tdonohue commented Nov 10, 2017

Further testing on Ubuntu 16.04:

  • AwsLambdoraApplicationIT (in lambdora-services) PASSES all tests
  • LambdoraLdpIT (in lambdora-http-api) FAILS all tests.

They are similar IT tests in nature, as they both use Dagger to build a mock application. However, LambdoraLdpIT wraps that Dagger application in a JerseyApplication, and uses a JerseyRequestHandler: https://github.com/duraspace/lambdora/blob/master/lambdora-http-api/src/test/java/org/fcrepo/lambdora/ldp/integration/LambdoraLdpIT.java#L63

Whereas, AwsLambdoraApplicationIT runs tests against the Dagger application directly: https://github.com/duraspace/lambdora/blob/master/lambdora-service/src/test/java/org/fcrepo/lambdora/service/aws/AwsLambdoraApplicationIT.java#L37

@tdonohue
Copy link
Member Author

On Ubuntu 16.04, looking at the detailed test output (lambdora-http-api/build/test-results/test/TEST-org.fcrepo.lambdora.ldp.integration.LambdoraLdpIT.xml), I see the following errors during the initial requests to the mock server:

21:49:17.514 [Test worker] DEBUG com.amazonaws.AmazonWebServiceClient - Internal logging successfully configured to commons logger: true
21:49:17.555 [Test worker] DEBUG com.amazonaws.metrics.AwsSdkMetrics - Admin mbean registered under com.amazonaws.management:type=AwsSdkMetrics
21:49:19.587 [Test worker] DEBUG com.amazonaws.regions.InstanceMetadataRegionProvider - Ignoring failure to retrieve the region: Unable to contact EC2 metadata service.
21:49:19.691 [Test worker] INFO com.amazonaws.serverless.proxy.internal.LambdaContainerHandler - Starting Lambda Container Handler
21:49:19.777 [Test worker] DEBUG org.fcrepo.lambdora.ldp.JerseyRequestHandler -

Notice the third DEBUG line, which says Ignoring failure to retrieve the region: Unable to contact EC2 metadata service. On a machine where these tests succeed, I do not see that "failure" message.

@tdonohue
Copy link
Member Author

tdonohue commented Nov 10, 2017

SOLUTION: It seems our LambdoraLDPIT tests REQUIRE that an AWSCLI default profile exists, and a region is configured locally.

I've gotten the tests to now succeed in Ubuntu 16.04, by simply creating a ~/.aws/config file, and adding the following to it:

[default]
region = us-east-1

(Strangely, it doesn't seem to work even if I simply set the AWS_DEFAULT_REGION environment variable)

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

No branches or pull requests

1 participant