Region found in serverless.yml is not getting variable expanded

[shentonfreude]

I'm deploying to different stages (shentonfreude, dev, test, prod) and each may have a different region defined in serverless.yml stage variables file custom_stage_variables.yml:

custom:
  stage: ${opt:stage, self:provider.stage}
  stage_variables: ${file(custom_stage_variables.yml)}
  client:
    bucketName: vmessage-frontend-${self:custom.stage}
    distributionFolder: vmessage/client
  region: ${self:custom.stage_variables.${self:custom.stage}.region}

Then the provider defines region, so that Finch can find it:

provider:
  name: aws
  runtime: python3.6
  region: ${self:custom.region}
  # ...

But when I try to deploy the client, it looks like Finch is not expanding the region variable:

$ sls client deploy --stage shentonfreude
Serverless: Deploying client to stage "shentonfreude" in region "${self:custom.region}"...
Serverless: Creating bucket vmessage-frontend-shentonfreude...
 
  Serverless Error ---------------------------------------
 
  A conflicting conditional operation is currently in progress against this resource. Please try again.

S3 is lying here, there's no resource conflict -- I think it just doesn't know what to do with "${self:custom.region}", since it's not expanding to "us-east-1" or "ap-southeast-2".

Am I using it wrong? or does Finch need to run the template interpolation over these variables, perhaps around here?
https://github.com/fernando-mc/serverless-finch/blob/master/index.js#L33

[fernando-mc]

@shentonfreude can you provide a simplified example that still demonstrates the break? Right now I'm trying to read through your example but you're referencing files that aren't included.

Edit - Specifically the custom_stage_variables.yml and the remaining portions of the provider config. Don't send me secrets or anything, but helping me have an easy reproduction on my end would be great! Thanks!

If you're convinced that's the problem then I'd also encourage you to throw in a PR for a fix and I'll test things on what's breaking for you now and apply/test the fix.

[shentonfreude]

OK @fernando-mc, I'll try to come up with a more simple example. I can take a whack at a fix but Node's not my strong suite. Hopefully later today.

[fernando-mc]

Sounds great. Thanks @shentonfreude!

[shentonfreude]

Sadly, I'm not node-smart enough to solve the problem but have created what I hope is a minimal full example that demonstrates the problem. I've put it up in a repo here:
https://github.com/v-studios/TestFinchStageRegion

But for TL;DR, if I have:

service: TestFinchStageRegion
plugins:
  - serverless-finch
custom:
  stageVars:
    dev:
      region: us-east-1
    prod:
      region: us-east-2
  region: ${self:custom.stageVars.${self:provider.stage}.region}
  client:
    bucketName: testfinch-${self:provider.stage}
    distributionFolder: client

provider:
  name: aws
  runtime: python3.6
  stage: ${opt:stage}
  region: ${self:custom.region}
  #region: ${self:custom.stageVars.${self:provider.stage}.region}

I then see Finch not expanding the region in its message, then you'll notice undefined in the S3 website endpoint spec at the end -- it's not able to lookup the URL with that bad region name:

$ sls client deploy --stage dev
Serverless: Deploying client to stage "dev" in region "${self:custom.region}"...
Serverless: Bucket testfinch-dev exists
Serverless: Listing objects in bucket testfinch-dev...
Serverless: Deleting all objects from bucket testfinch-dev...
Serverless: Configuring website bucket testfinch-dev...
Serverless: Configuring policy for bucket testfinch-dev...
Serverless: Configuring CORS policy for bucket testfinch-dev...
Serverless: Uploading file index.html to bucket testfinch-dev...
Serverless: If successful this should be deployed at:
Serverless: http://testfinch-dev.undefined/index.html

It doesn't help to use a more complex variable in provider.region to avoid a second lookup.
If I'm doing something stupid, let me know!

[fernando-mc]

@shentonfreude Thanks for providing that repo and the extra information here. I've tested it myself and confirmed the issue.

I think you're correct and this is a bug in the plugin - the Serverless Framework itself appears to evaluate the code you're using correctly. (I was able to use basically the same file to create a dynamoDB table that correctly created with the correct name - in this case us-east-1 when using sls client deploy --stage dev).

I'm not sure how soon I'll be able to patch and test this myself but I'll make it the next thing I work on related to this plugin. I definitely suggest trying to put a patch PR in for the issue for me to review as that will likely be a faster way to get it resolved.

[shentonfreude]

Thanks for confirming @fernando-mc. I'll take a look but I'm a python guy and my node chops aren't even good enough yet to know how to print something :-( If I can figure out why it's not resolving and come up with a fix, I'll post a PR for sure.

[shentonfreude]

This fix seems to solve the problem, but I'll admit to being a bit out of my depth.
Demo against my minimal example:

chris@Haruspex:vmsg-hack-region$ sls client deploy --stage dev
Serverless: Deploying client to stage "dev" in region "us-east-1"...
Serverless: Bucket testfinch-dev exists
...
Serverless: If successful this should be deployed at:
Serverless: http://testfinch-dev.s3-website-us-east-1.amazonaws.com/index.html

(.venv3) chris@Haruspex:vmsg-hack-region$ sls client deploy --stage prod
Serverless: Deploying client to stage "prod" in region "us-east-2"...
Serverless: Bucket testfinch-prod exists
...
Serverless: If successful this should be deployed at:
Serverless: http://testfinch-prod.s3-website.us-east-2.amazonaws.com/index.html

[fernando-mc]

@shentonfreude Great! I'll try to test the fix this weekend.

[fernando-mc]

Fixed by #18