Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reference a randomly named bucket? #4

Open
cnuss opened this issue Apr 3, 2024 · 1 comment
Open

Reference a randomly named bucket? #4

cnuss opened this issue Apr 3, 2024 · 1 comment

Comments

@cnuss
Copy link

cnuss commented Apr 3, 2024

I have a S3 bucket in serverless.yaml resources:

resources:
  Resources:
    Bucket:
      Type: AWS::S3::Bucket
      Properties:
        BucketEncryption:
          ServerSideEncryptionConfiguration:
            - ServerSideEncryptionByDefault:
                SSEAlgorithm: 'AES256'

Note: I've left off the BucketName property, so I get a random-ish bucket name.

In serverless.yaml its possible to use the Ref syntax for dynamic injection of the bucket name, for example with environment:

provider:
  name: aws
  # ...SNIP...
  environment:
    BUCKET_NAME: { Ref: Bucket }

Is there a method to "inject" the randomized bucket name from CloudFormation State? Ideally I'd like to do something like:

plugins:
  - serverless-s3-cleaner

custom:
  serverless-s3-cleaner:
    prompt: false
    buckets:
      - { Ref: Bucket } # or something similar to get the bucket name
@cnuss cnuss changed the title Use "ref" syntax? Reference a randomly named bucket? Apr 3, 2024
@coyoteecd
Copy link
Owner

@cnuss that won't work for the reasons explained here. The plugin must run before (re)deploying a stack, since its main purpose is exactly to clear out the bucket before the stack deployment runs, otherwise it fails.

This means that embedding a !Ref does not work; this only works for plugins that modify the stack template.

The closest you would get is that cf:stackName example that I've shown in the referenced comment. At the time of posting it, that did not work because Serverless Framework was attempting to resolve the variables and would fail because (obviously) the stack is not yet deployed when first running a deploy. I haven't tried it since, maybe you could try to get it to fall back to a default value when the stack does not exist...?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants