designs/package_during_deploy.md
sam deployToday while using sam deploy the specified --template-file or --template is expected to have packaged artifacts references in the given template file.
This is driven by the following workflow.
sam build -> sam package --s3-bucket ... --s3-prefix ... --output-template-file packaged.yaml.
This workflow builds the requisite code and packages those built artifacts into an s3 bucket, optionally under a given s3 prefix.
If a developer can optionally cut through this process without requiring an explicit package command, but rather have sam deploy package to a given s3 bucket, it cuts the number of steps before needing to deploy and test in the cloud.
This also reduces friction in the author and test loop.
Ideal end state.
sam build -> sam deploy ..... --s3-bucket ....
Addition of extra parameters that are currently supported by sam package over to sam deploy with all of them being optional.
Additional parameters that need to be on sam deploy that are not on sam package.
--metadata--use-jsonParameters that dont need to be added.
--output-template-fileoutput-template-file is created on the fly during packaging in the deploy phase.If the expectation is to package and deploy in one command, One can now do.
sam deploy --stack-name sam-package-on-deploy --capabilities CAPABILITY_IAM --s3-bucket sam-package-bucket
There is no explicit need to pass in a --template-file or --template parameter, if one is not passed in it to defaults to trying to find the template.yaml that was generated by sam build which is located at .aws-sam/build/template.yaml
The old method of deploying pre-packaged artifacts will continue to work as before.
sam deploy --template-file packaged.yaml --stack-name sam-package-on-deploy --capabilities CAPABILITY_IAMIf a deployment is done without running sam build prior we still go ahead and deploy with the given template.yaml in the project root. This might still result in a successful deploy, but not a deploy with the correct build artifacts.
sam package?sam package will continue to exist in the state it is today and will continue to be improved upon separately.User do not require to run sam package as part of their author test loop, except for CI/CD purposes, where sam package can be run and the packaged template file can be passed to cloudformation deploy actions.
The s3 bucket where the packaged artifacts go is not abstracted in this design. In the future, the s3 bucket could be specified via a configuration file.
This is currently in design in : https://github.com/awslabs/aws-sam-cli/pull/1503
sam build -> sam deploy
sam build -> sam package -> sam deploy
Provide identical experiences in terms of a deploying the same stack, with exactly same artifacts.
--metadata, --use-json and modify existing --template-file or --template to look for a default template.yaml that exists under .aws-sam/build/--kms-key-id , if a kms-key-id is specified that same key is used across both packaging and deploy purposes..samrc ChangesNone
What new dependencies (libraries/cli) does this change require? N/A
What other Docker container images are you using? N/A
Are you creating a new HTTP endpoint? If so explain how it will be created & used N/A
Are you connecting to a remote API? If so explain how is this connection secured N/A
Are you reading/writing to a temporary folder? If so, what is this used for and when do you clean up?
Possibly reading from a configuration file in the future.
How do you validate new .samrc configuration?
N/A
sam deploysam deployN/A
sam deploy --template-file packaged.yaml --stack-name sam-stack --capabilities CAPABILITY_IAM
sam deploy --stack-name sam-stack --capabilities CAPABILITY_IAM
The new stack should not have any changes.
--template-file, --template parameter has a series of defaults that are looked at during sam deploy similair to sam package.--template-file or --template points to a non-packaged template-file, --s3-bucket becomes required to be able to effectively package and deploy in one command using sam deploy.