Open aaronjensen opened 5 years ago
Same problem when starting serverless offline with dynamodb custom config:
dynamodb:
start:
port: 8002
inMemory: true
migrate: true
When serverless offline start
I get the error Serverless: Skipping start: DynamoDB Local is not available for stage: dev
Thanks!
looks like this pr: https://github.com/99xt/serverless-dynamodb-local/commit/5e53d7622d901bc05515135cd91de04a6680d38e
@rehrumesh any ideas?
Solved it by adding the stage to the stages whitelist.
custom:
dynamodb:
stages:
- test
stages: direction works
seems this bug has bitten our developers as well.
So we now have to whitelist all of our stages or just our local ones?
I started getting this error with 0.2.37 this morning, and the whitelist strategy from @rhnorskov worked for me. One slight difference from the OP is that I'm running sls offline start
and was getting Skipping start: DynamoDB Local is not available for stage: dev
.
@99xt - there is nothing in this repo about the commit that caused 0.2.38 - can you advise ?
custom:
dynamodb:
stages:
- test
works but in my case, had to remove and reinstall dynamodb.
custom:
dynamodb:
stages:
- test
works for me, thanks
For all stages:
custom:
dynamodb:
stages:
- ${self:provider.stage}
Unfortunately the solution with whitelisting a stage does not work if your custom
key is included from a file.
In our case:
custom:
${file(serverless/custom.yml)}
is enough to prevent DynamoDB from starting up when on 0.2.38. The core of the issue stems in my opinion from the fact that this.config
is assigned in constructor(serverless, options) {...}
where the actual content of the file has not been processed by Serverless and, thus, custom
is properly defined yet.
BTW. It looks like this is already reported as #229
For us the solution was to revert to 0.2.37 which checked the whitelist in a different manner and did not prevent DynamoDB from running (though the bug with reading config too early already exists there).
The stage whitelisting worked for me. I just added the two stages i'm going to use it at. I don't think it is worth using a wildcard. Thank you very much, I was starting from an official sls tutorial and this was driving me crazy
It looks like you released a new patch version and I don't see any release notes or instructions. This change was a breaking change for us in CI. We now get:
Actual Behaviour
When running:
We get:
Expected Behaviour
It would work as it did before or be released as a new minor or major version with migration instructions.
Steps to reproduce it
See above
LogCat for the issue
See above
Screenshots of the issue
None
Would you like to work on the issue?
No thank you