Skip to content

Question: How do references to other components' output work? #16

Open

Description

@jedfoster

This is a more general question about working with Serverless Components, not necessarily specific to this repo. If there's a better place to post this, let me know.

The API component in this repo references output from the permissions and database components. How does that work?

See api/serverless.yml lines 9, 17, and 19:

component: express
app: fullstack
name: api

inputs:
  # Express application source code.
  src: ./
  # Permissions required for the AWS Lambda function to interact with other resources
  roleName: ${output:permissions.name}  # <<--- _HOW_ does this work??

AFAICT, the only linkages between the API component and the permissions component are the app values, and directory structure (api/ and permissions/ being siblings).

I'm trying to add a layer to a lambda using those conventions—sibling directories, same app values—but I keep getting invalid reference ${output:commoncode.arnVersion}. What am I missing? How do these output references work?

Activity

  1. tommedema commented on Nov 9, 2020

    @tommedema

    Same question here.

    Similarly, if you run serverless deploy in the root folder, how does it know the dependency graph to define the order of operations in which to deploy? I.e. the database must be deployed prior to the api etc.

  2. eahefnawy commented on Jan 4, 2021

    @eahefnawy
    Member

    The output variable format is like this:

    ${output:<instanceName>.<outputName>}
    

    This would find the instance named instanceName in the same app & stage you're deploying to. So in your case, the instance name is permissions. You can confirm that by looking at the name property of the yaml file inside the permissions folder.

    @tommedema the CLI collects all the yaml files in child directories and does some basic static analysis, to figure out the output references.

  3. tommedema commented on Jan 4, 2021

    @tommedema

    @eahefnawy does it then do a graph analysis to ensure that dependencies are deployed prior to dependents etc.?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions