appspec.yml pattern and exclude file globs

[ndench]

It would be great if the pattern and exclude keys accepted bash file globs and worked properly across sub directories. For example, I have a Symfony4 app that looks like:

bin/
    console
config/
    services.yaml
public/
    index.php
src/
    MyController.php
templates/
    my_template.html.twig

I want all directories to have mode 750 and all files to have mode 640. Except for the bin/console file which needs mode 750.

This is the config that I've tried in appspec.yml:

version: 0.0
os: linux 

files:
  - source: /
    destination: /srv/www/app/

permissions:
  - object: /srv/www/app
    owner: ubuntu
    group: www-data
    mode: 750
    type:
      - directory
  - object: /srv/www/app
    pattern: '**'
    except:
      - bin/console # also tried 'console' and 'bin/*' and '/srv/www/app/bin/console'
    owner: ubuntu
    group: www-data
    mode: 640
    type:
      - file
  - object: /srv/www/app/bin
    owner: ubuntu
    group: www-data
    mode: 750
    type:
      - file

But I get the following error:

The deployment failed because the permissions setting for (/srv/www/app/bin/console) is specified more than once in the application specification file. Update the files section of the AppSpec file, and then try again.

I can't seem to find a value which I can put in the except key that successfully excludes the bin/console file. If it supported bash file globs you could easily do something like bin/* because all the files in the bin directory are going to need different permissions.

[tomtomau]

Facing the same issue!

[rohkat-aws]

@tomtomau not sure if this is a bug seems more like a feature request

[andrispraulitis]

Yeah at the moment it seems impossible to exclude (using except) one nested nested folder.

[sanju784]

Facing same issue!!
Even after an year haven't they provided any solution yet???

[expertcoder]

I'm experiencing the same issue. Been trying different things cant get it to work.

[arick]

Internally, they've acknowledged that this a bug, and that it is on their bug tracker. But, they have no estimate on when, or if, they will ever address it.
When you correlate this bug, with the bug on Debian/Ubuntu distributions, where AWS CodeDeploy erases the time/date stamp information on all the files, It seems pretty obvious that either the AWS architects don't understand the criticality of file metadata, or they don't care. Either way, as a consequence, the whole AWS CodePipeline, AWS CodeDeploy etc. is:

1. More of a proof of concept, than a reliable, enterprise service that you can really depend on, and that
2. Amazon doesn't consider it to be a strategic asset.

[philstrong]

The request makes sense. I think we should consider adding a warning and not an error when there is overlap. I believe the original author was trying to stop weird behavior from happening where the last one wins. It's possible that some customers will have dozens of entries and so wouldn't be as easy to identify that you've already set perms on a directory.

Team will triage to understand LOE and dig up the history of why original rule was set.

[philstrong]

AWS CodeDeploy erases the time/date stamp information on all the files

Link?

[philstrong]

My recommendation wouldn't be to exclude but rather to allow the last one to win. Meaning if you get more specific later e.g. next subfolder down it will set that last.

It will still warn that you have already set permissions but will still allow you to do so.

Will this work? Not sure I understand what end permissions you want or the entire file struct from example above

[ppostma1]

After the directive for the permissions of directory: /srv/www/app, I can no long append directives for that directory /srv/www/app, pattern: '**' nor any of its children /srv/www/app/bin
I deleted these directives, and move the commands to the shell file application_start.sh with chown user:group /files and chmod 640 /files. Removing these declarations allowed it to deploy without error and the chown/chmod commands completed the required objectives.