I had Travis CI setup for CICD of my Angular Project. I have been using this seamlessly since 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 have changed nothing that should cause this error. I've just made some Typescript and HTML changes and not installed any new packages or changed anything on my AWS end.
LOG :
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
It appears that you may be hitting this issue with Travis' deploy system. We hit this same issue several days ago, after many months of smooth deployments.
We have an AWS_SECRET_ACCESS_KEY value, which is encrypted for our build, and our YAML config in the deploy section looked like this:
access_key_id: $AWS_ACCESS_KEY_ID
secret_access_key:
secure: $AWS_SECRET_ACCESS_KEY
The linked issue mentions:
You are using the plain text value in the secure value. We rolled out additional changes to data processing so that we can prevent accidental exposures of these secrets.
Your configuration was working before because we were passing through values when the decrpytion fails in such a case.
Please try changing this configuration to:
secret_acces_key: $AWS_SECRET_KEY
Based on this, we changed our config to the following:
access_key_id: $AWS_ACCESS_KEY_ID
secret_access_key: $AWS_SECRET_ACCESS_KEY
This fixed the issue for us.