Describe the bug
The refactoring from #51 started using --profile default by default, instead of omitting the option entirely. AWS CLI seems to consider these two different things, so our build fails if we try to use the latest release.
To Reproduce
Set environment variables only, without configuring an AWS CLI profile: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN. In our case, these values came from aws sts assume-role.
Then run the aws-s3/sync job. Starting with v4.0.0, it fails with an error: "The config profile (default) could not be found"
Expected behavior
It works fine in v3.1.1 of the orb.
Additional context
v4.0.0 happens to be the only version that doesn't trigger a deprecation warning from CircleCI, so we're strongly motivated to upgrade. Otherwise we see this: "This job is using a deprecated deploy step, please update .circleci/config.yml to use a run step"
Orb Version 4.0.0
Describe the bug The refactoring from #51 started using
--profile defaultby default, instead of omitting the option entirely. AWS CLI seems to consider these two different things, so our build fails if we try to use the latest release.To Reproduce Set environment variables only, without configuring an AWS CLI profile: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN. In our case, these values came from
aws sts assume-role.Then run the
aws-s3/syncjob. Starting with v4.0.0, it fails with an error: "The config profile (default) could not be found"Expected behavior It works fine in v3.1.1 of the orb.
Additional context v4.0.0 happens to be the only version that doesn't trigger a deprecation warning from CircleCI, so we're strongly motivated to upgrade. Otherwise we see this: "This job is using a deprecated deploy step, please update .circleci/config.yml to use a run step"