error: argument --acl: Invalid choice / Unknown options: --acl

[swiknaba]

Orb Version circleci/aws-s3@3.1.1

Describe the bug In Orb version 2.x, I was using the following syntax:

- aws-s3/sync:
    arguments: |
      --acl=public-read \
      --cache-control="max-age=86400"

note that acl=public-read has a = in the command. The AWS CLI (to my knowledge) supports both variations; typically, CLI tools would support both, with the reason for supporting = to avoid ambiguity when the value for an argument starts e.g. with a dash like in foo -1vs. foo=-1 makes clear, that the first is not a syntax error).

After upgrading the Orb to 3.x, the above syntax fails with:

usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:

  aws help
  aws <command> help
  aws <command> <subcommand> help

aws: error: argument --acl: Invalid choice, valid choices are:

private                                  | public-read                             
public-read-write                        | authenticated-read                      
aws-exec-read                            | bucket-owner-read                       
bucket-owner-full-control                | log-delivery-write                      

Exited with code exit status 252

The CircleCi docs document this command with a space instead of =, fair enough, so I changed it to:

- aws-s3/sync:
    arguments: |
      --acl public-read \
      --cache-control "max-age=8640"

which now results in

Unknown options: --acl public-read --cache-control max-age=86400

Exited with code exit status 252

Here the full snippet I use:

jobs:
  sync-bucket:
    resource_class: small
    docker:
      - image: cimg/base:current
    steps:
      - checkout
      - attach_workspace:
          at: .
      - aws-s3/sync:
          arguments: |
            --acl public-read \
            --cache-control "max-age=86400"
          from: public
          to: 's3://my-bucket'

Using Orb version 2.x, both variations (space and =) work btw.

To Reproduce

see above snippet

Expected behavior

It's expected to work as documented

Additional context

I saw, that the example uses cimg/python:3.10 as an image, and I wonder why? Why should I as a user need to know/care, that the AWS CLI under the hood is written in python? There is no obvious use of python, plus, AWS might change the language.

Shouldn't this dependency rather be inside the Orb, so that I can use the base image?

https://github.com/CircleCI-Public/aws-s3-orb/blob/master/src/executors/default.yml#L16

The orb actually uses the AWS image, which builds on top of cimg/deploy which installs python actually https://github.com/CircleCI-Public/cimg-deploy/blob/main/2023.07/Dockerfile#L14

I've also tested running the orb in a job that uses the base image, and that works.

Quite frankly, I came across breaking changes with almost every Orb's major version update, and I never found any proper documentation on those breaking changes. Often, they were bugs :( For lots of the AWS-related Orbs, I'm using year-old versions since newer versions all are way too buggy :( -- I suspect some underlying issue regarding the quality of the codebase for this.

[brivu]

Hey @swiknaba! I am going to release that latest version of this orb today which will contain a fix for this issue.

In the tests for the latest version, I ran a test with the arguments on a single line and it worked.

If you're using multi-line, You need to replace the | with >- instead like below:

      - aws-s3/copy:
          from: "bucket/build_asset.txt"
          to: "s3://orb-testing-1"
          profile_name: "OIDC-User"
          arguments: >-
            --cache-control "public, max-age=15" 
            --acl bucket-owner-full-control

Feel free to give version 4.0 a try and let me know if it works.