Unable to get variables when files are in different folders

Need some help with my aws configuration.
I have multiple services with its own serverless.yml but i do have another serverless.yml at root, which contains some services (for reasons) and a resources.serverless.yml

// Here's the folder struct
- services
   - A
     - serverless.yml
   - B
   - C
- serverless.yml (for B and C)
- resources.serverless.yml
// ./services/A/serverless.yml
projectDir: ../../

      - sqs:
          arn: !Ref EventSomething

  Resources: ${file(../../resources.serverless.yml):Resources}
// ./serverless.yml
    name: bee

  Resources: ${file(./resources.serverless.yml):Resources}
// ./resources.serverless.yml

   Type: AWS::SQS::Queue
   Type: AWS::SNS::Topic
     TopicName: ${file(./serverless.yml):functions.C.name}-DL

When i try to build and deploy A, this is the error i get

Cannot resolve serverless.yml: Variables resolution errored with:
- Cannot resolve variable at “resources.ResourcesEVENTC.Properties.TopicName”: Value not found at “file” source,

When i change the relative pathing in resources.serverless.yml to ../../serverless.yml, it works!

Clearly the file import’s relative path is all out of whack. If i do keep it to that then i can’t deploy my ./serverless.yml as that relative path of ../../ would be wrong!

How can i achieve my setup? Or should i be thinking about this a different way.
Mainly i’m just trying to be DRY

@jonyeezs Unfortunately file variable paths in the Framework are always (even in imported files) resolved in relation to the service directory.

So in case of A, service directory is ./services/A so file(./serverless.yml) (as listed in ./resources.serverless.yml) will reach for ./services/A/serverless.yml (and not ./serverless.yml as you probably anticipate).

It’s a known issue (see Variables: ${file..} source paths resolved always against service path · Issue #6039 · serverless/serverless · GitHub), we plan to address it at some point, but currently, ETA is unknown (it’ll always help to +1 on that)

In your case, the best way to mitigate that, would be to place all service configuration at same level som for B at ./services/B and for C at ./services/C

1 Like