Root serverless stage overrides provider.stage in sub-service

[spock-yh]

Are you certain it's a bug?

• Yes, it looks like a bug

Are you using the latest version?

• Yes, I'm using the latest version

Is there an existing issue for this?

• I have searched existing issues, it hasn't been reported yet

Issue description

If the sub-project serverless.yml has an explicit provider.stage setting, then:

1. Invoking serverless from the sub-project directory uses that stage, regardless of the stage command line option
2. Invoking serverless from the root where serverless-compose.yml exists uses whatever stage was provided in the command line, ignoring the setting in the sub-project serverless.yml file.

Explicitly specifying provider.stage is useful when we want to deduce the stage based on various inputs. For example, we use it to automatically create a stage per developer when working locally. This works nicely when serverless is executed in the sub-project, but not in serverless compose. Since we can't include the same stage-deduction logic in serverless-compose.yml, there is also no workaround.

This can be verified by specifying a provider.stage that is different from "dev" in serverless.yml and then running serverless <service>:print or serverless <service>:package in the root.

Service configuration (serverless-compose.yml) content

N/A

Command name and used flags

serverless :print

Command output

N/A

[mnapoli]

Hi, this is intentional that the stage is overridden from the root when using Compose. Could you clarify what you are trying to achieve and what you would expect to happen?

[spock-yh]

Before I tried to use compose, I had my serverless.yml set up with:

provider:
   stage: ${file(./serverless-stage.js)}

Where the serverless-stage.js file is:

module.exports = async ({ _, resolveVariable }) => {
    const stage = await resolveVariable("opt:stage,'dev'");
    if (stage == "dev") {
        const user = process.env.USERNAME || process.env.USER || "undefined_user";
        return user.replace(/[^a-zA-Z0-9_\-]/g, "").toLowerCase();
    }
    return stage;
};

The idea is to automatically detect what stage was requested (default to dev if none was explicitly requested), and if that stage is dev, replace the stage with the username of the developer. This works nicely and allows every developer to automatically deploy to their own stack without interfering with other developers' resources. Perhaps having an AWS account per developer would be better but that's not a setup we have in place now and it's not a trivial transition.

In any case, when I tried using this in a sub-service of serverless compose, it stopped working. I added some printouts to debug it and it seems that while the JS file is still being called, and it does return the correct stage (the username), the provider.stage field is ignored altogether. I verified this by just typing a static bogus stage in that field, which was also ignored (my cloudformation stack name and resource names had dev in them).

Can you explain the reasoning behind having compose override the provider stage? Shouldn't compose honor the specific settings of each sub-service?

[r-token]

Related: I'd like Compose to use a new "dev2" stage as the default stage (instead of "dev"). I thought updating provider.stage to "dev2" in all services would do this for me, but as @spock-yh mentioned – Compose ignores the provider.stage setting for the individual services and defaults to "dev" if no stage is specified in the command.

Is there a way to set the default stage for Compose @mnapoli?

[mnapoli]

Hi both, I see what you mean. Unfortunately for now the default stage is hardcoded to dev (

compose/src/index.js

Line 108 in d145ecc

const stage = options.stage || 'dev';

) and cannot be changed.

Full transparency, I am no longer at Serverless Inc. and no longer a maintainer on this repository, so I cannot really help with new features. Sorry about that!

[r-token]

Oh no! I'll miss interacting with you here. Great work on Compose, it has been a huge boost for our team. And thanks for confirming that the default stage is hardcoded. We'll just get in the habit of always specifying the --stage {stage} flag.

Is there a new primary maintainer on this repository that we should get in contact with for future requests?

[mnapoli]

Thank you :) Unfortunately I don't know.