Open davecarlson opened 5 years ago
Yeah we have to fetch the current state of the world, because migrations are sticky
I wonder if we could just do the split on deploy*
I believe this should be done as part of deploy since we are running into same issue and we don't use deploy feature, rather rely on AWS to create change set by comparing stack in different aws accounts. Seems like the plugin assumes that stack is deployed in the same environment which is not the case.
I'm fine with moving it to deploy, but it's very unlikely it will work with changesets. Nested stacks and change sets are basically unsupported by AWS
I am not sure how this will handle a scenario where CI builds are executed in a different environment where no other stack exists. Build Setup CI Environment Code Pipeline Run build and create cloud formation template Dev Transition Codepipeline create changeset by comparing cloudformation template and then execute the same Sandbox Transition Upon approval changeset is created by comparing the cloudfomration generated during build against sandbox environment and a similar process is followed for other environments.
This used to work in the old version and stopped working with the latest release.
The ChangeSet will generate, it will just show 'MODIFIED' for all the nested stacks, and won't show you any details of them. This is CloudFormation behaviour, not Serverless/this plugin.
If you can work around that, with deploy hook, then we're OK?
In our workflow,
sls package
is run separately to the deploy step.When adding in this plugin, I am receiving the following error when doing
sls package
:I cannot see anything that calls that that AWS cli access is required in the README, and wouldn't normally expect it to be needed for packaging. Is this by design, or is it doing something that requires AWS access?
serverless.yml: