Travis CI build failed - (Aws::S3::Errors::SignatureDoesNotMatch) (React + Prisma)

Deployment
,
1

I had Travis CI setup for CI/CD of my React project using Prisma. I’ve been using this seamlessly for 2 months now. Having no trouble. But since 2 days my builds are continuously failing and I’m not able to figure out the exact cause from the Build Log, I’m thinking it has something to do with React or Prisma. For example the should pass build:

import React from 'react';

But doesn’t when Prisma is running, when Prisma is shut down it will build.

I have changed nothing that should cause this error. I’ve just made some React and HTML changes and not installed any new packages or changed anything on my AWS end.

Deploying application
uploading "04.0284d042a6c29213aaa1.png" with {:content_type=>"image/png", :acl=>"public-read"}
uploading "Roboto-Bold.dc81817def276b4f2139.woff" with {:content_type=>"font/woff", :acl=>"public-read"}
uploading "arrow_left.270f72df47e036d9cfa1.svg" with {:content_type=>"image/svg+xml", :acl=>"public-read"}
uploading "fa-solid-900.1709a2810c3752483683.ttf" with {:content_type=>"font/ttf", :acl=>"public-read"}
uploading "Roboto-Regular.2751ee43015f9884c364.woff2" with {:content_type=>"font/woff2", :acl=>"public-read"}
/home/travis/.rvm/gems/ruby-2.4.5/gems/aws-sdk-core-2.11.394/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call': The request signature we calculated does not match the signature you provided. Check your key and signing method. (Aws::S3::Errors::SignatureDoesNotMatch)
    from /home/travis/.rvm/gems/ruby-2.4.5/gems/aws-sdk-core-2.11.394/lib/aws-sdk-core/plugins/s3_sse_cpk.rb:19:in `call'
    from /home/travis/.rvm/gems/ruby-2.4.5/gems/aws-sdk-core-2.11.394/lib/aws-sdk-core/plugins/s3_dualstack.rb:24:in `call'
    from /home/travis/.rvm/gems/ruby-2.4.5/gems/aws-sdk-core-2.11.394/lib/aws-sdk-core/plugins/s3_accelerate.rb:34:in `call'
    from /home/travis/.rvm/gems/ruby-2.4.5/gems/aws-sdk-core-2.11.394/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'
    from /home/travis/.rvm/gems/ruby-2.4.5/gems/aws-sdk-core-2.11.394/lib/aws-sdk-core/plugins/idempotency_token.rb:18:in `call'
    from /home/travis/.rvm/gems/ruby-2.4.5/gems/aws-sdk-core-2.11.394/lib/aws-sdk-core/plugins/param_converter.rb:20:in `call'
    from /home/travis/.rvm/gems/ruby-2.4.5/gems/aws-sdk-core-2.11.394/lib/seahorse/client/plugins/response_target.rb:21:in `call'
    from /home/travis/.rvm/gems/ruby-2.4.5/gems/aws-sdk-core-2.11.394/lib/seahorse/client/request.rb:70:in `send_request'
    from /home/travis/.rvm/gems/ruby-2.4.5/gems/aws-sdk-core-2.11.394/lib/seahorse/client/base.rb:207:in `block (2 levels) in define_operation_methods'
    from /home/travis/.rvm/gems/ruby-2.4.5/gems/aws-sdk-resources-2.11.394/lib/aws-sdk-resources/services/s3/file_uploader.rb:42:in `block in put_object'
    from /home/travis/.rvm/gems/ruby-2.4.5/gems/aws-sdk-resources-2.11.394/lib/aws-sdk-resources/services/s3/file_uploader.rb:49:in `open_file'
    from /home/travis/.rvm/gems/ruby-2.4.5/gems/aws-sdk-resources-2.11.394/lib/aws-sdk-resources/services/s3/file_uploader.rb:41:in `put_object'
    from /home/travis/.rvm/gems/ruby-2.4.5/gems/aws-sdk-resources-2.11.394/lib/aws-sdk-resources/services/s3/file_uploader.rb:34:in `upload'
    from /home/travis/.rvm/gems/ruby-2.4.5/gems/aws-sdk-resources-2.11.394/lib/aws-sdk-resources/services/s3/object.rb:252:in `upload_file'
    from /home/travis/.rvm/gems/ruby-2.4.5/gems/dpl-s3-1.10.13/lib/dpl/provider/s3.rb:114:in `block (2 levels) in upload_multithreaded'
failed to deploy

Thanks
SU

2

I’ve seen this problem several days ago, the developer also complained of ‘many months of smooth deployments using Travis.’

You have an AWS_SECRET_ACCESS_KEY value, which is encrypted for your build, and your .travis.yml config in the deploy section probably looked like this:

access_key_id: $AWS_ACCESS_KEY_ID
secret_access_key:
secure: $AWS_SECRET_ACCESS_KEY

Based on this, change your config to the following:

access_key_id: $AWS_ACCESS_KEY_ID
secret_access_key: $AWS_SECRET_ACCESS_KEY

That should fix the issue at hand. Let me know if this solves the issue. This can be common when running things like Prisma or GraphQL.