-
Notifications
You must be signed in to change notification settings - Fork 15
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
serverless [service]:package fails if another service refers as params #148
Comments
Actually, deployment for command error log
|
Could it be that the service has been deployed from another machine? (https://www.serverless.com/framework/docs/guides/compose#refreshing-outputs) You might want to refresh the outputs stored locally with:
|
@mnapoli npm run sls:refresh -- --stage [stage-name] // sls:refresh: "serverless refresh-outputs"
> [email protected] sls:refresh
> serverless refresh-outputs "--stage" "[stage-name]"
Refreshing outputs
✔ service-a › outputs refreshed › 3s
✔ service-b › outputs refreshed › 4s
npm run sls:deploy -- service-a:deploy -- --stage [stage-name] // sls:deploy: "serverless deploy"
> [email protected] sls:deploy
> serverless deploy "service-a:deploy"
Environment: darwin, node 16.15.1, compose 1.2.4
Docs: slss.io/docs-compose
Bugs: github.com/serverless/compose/issues
Error:
The variable "${service-a.value1}" cannot be resolved: the referenced output does not exist.
Verbose logs are available in ".serverless/compose.log" |
Thanks. Could it be that the output simply doesn't exist? Could you run the command |
This is a bit of a chicken-and-egg situation for
tl;dr if we define params in the services:
service-a:
path: service-a
service-b:
path: service-b
params:
value1: ${service-a.value1}
value2: ${service-a.value2} |
Hey @semiautomatixfu, the |
@pgrzesik Additionally we're running
Thanks! |
That's very surprising - do you have a chance to provide a small reproducible example that I could run on my side to evaluate these issues? I couldn't reproduce it with my test services |
One thing I noticed is that, for me, The behavior seems stateful as well.
error. |
Some more testing suggests that |
For those looking for a workaround on this (similar to my suggested proposal here #149) , I ended up creating 2 serverless-compose.{stage}.yml, and then manually copying them to serverless-compose.yml in as |
Are you certain it's a bug?
Are you using the latest version?
Is there an existing issue for this?
Issue description
What I want to achieve
I want to package each service first to test before deployment. So I planned to package a service that outputs referred by another service first then a service depending on. However, the first packaging fails because another service depends on the output but I feel it shouldn't bother.
issue details
When service-b refers to the output of service-a as params in serverless-compose.yml, packaging service-a fails.
e.g.
I have the following serverless-compose.yml
I ran the following command
I get following error
Service configuration (serverless-compose.yml) content
Command name and used flags
npm run sls -- service-a:package --stage [stage-name] // package.json "scripts": { "sls": "serverless" }
Command output
The text was updated successfully, but these errors were encountered: